Feature: Integrate scan_logger.py Across the Application

[ankan123basu]

📌 Description:
The file scan_logger.py already exists in the codebase, but it is currently not being used or integrated with the application logic. This feature aims to introduce centralized and consistent logging throughout key components of the app using this logger module.

🔍 Why is this needed?
Right now, the application either uses print() statements or has no consistent logging mechanism. A unified logger offers multiple advantages:

Provides a standard way to track app activity.

Helps with debugging and error tracking.

Makes the codebase more professional and production-ready.

Easier to scale and maintain in the future.

I would love to take this up as a first issue. Please assign it to me! 🙌

[kavanatn]

Hi👋,

I'm Kavana, a GSSoC'25 contributor, and I’d love to work on integrating scan_logger.py into the core flow of the application.

Rather than treating this as just a "replace print statements" task, I’d like to approach it as a logging architecture revamp — ensuring logging is:

🔹 Context-aware: Logs will reflect which module/function raised them for easier debugging and traceability.
🔹 Level-specific: Introduce structured logging levels — DEBUG, INFO, WARNING, ERROR, and CRITICAL — to separate dev-time logs from production-level ones.
🔹 Minimal and centralized: Prevent log clutter and avoid repetition by registering one shared logger per module (no global chaos).
🔹 Extendable: Will structure the logger in such a way that it can be plugged into future features like file logging, external monitoring tools (like Sentry or Logstash), or even Discord/webhook alerts if needed.
🔹 Developer-friendly: Add optional color-coded logs (if allowed), helpful during active development sessions.

This change isn't just about aesthetics — it's about laying the foundation for a scalable, maintainable, and observability-ready backend.

Please assign this to me. I’m excited to get my hands on this and ensure the application logs smarter. 🔥

[ankan123basu]

Hi @kavanatn, thanks for your interest!

As per the contribution rules and general open-source etiquette, the person who raises the issue typically gets the first right to work on it — especially if they also offer a clear implementation plan.

[kavanatn]

Hi @ankan123basu 👋,

I totally understand and respect the point you made about the person raising the issue generally getting the first chance to work on it. However, as per GSSoC guidelines (confirmed with the coordinator), the final decision on issue assignment rests with the project admin/maintainers, who can choose to assign it to anyone based on priority, skill match, or availability.

My intention here is not to override your initiative, but to express my genuine interest in contributing to this feature. I’ve shared my detailed approach above so the maintainers can assess whether it aligns with the project’s vision, and decide accordingly.

Let’s allow the project admin to make the final call — there’s no need to rush. Even if your approach is selected, there’s nothing wrong with that; what matters most is delivering the best possible contribution to enhance the project.

Thanks for understanding! 😊

[shreeraksha2112]

Good morning, @ankan123basu n123basu and @kavanatn !

I’m Shreeraksha Adiga, your mentor for this project. Since both of you have expressed interest in working on this issue, I’d highly recommend collaborating to tackle it together.

Working as a team will not only help resolve the issue more efficiently but also provide you with valuable experience in teamwork, communication, and joint problem-solving skills that are essential in any professional environment. This is a great opportunity to learn from each other, share ideas, and create a stronger solution.

Let me know if you’d like any guidance on how to get started or coordinate your efforts. I’m happy to support you throughout the process.

Looking forward to seeing your collaboration in action!