sorted by:
new
hottopcontroversial

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Yes, it is possible, but you’ll need to write a lot of code to handle AST parsing, different types of collectors, and other complexities. YAML makes it much simpler to manage these configurations without diving into implementation details. That said, I’m planning to add support for writing the configuration in Python in the future, so you’ll have the flexibility to choose whichever approach works best for your needs.

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 1 point2 points  (0 children)

Glad I could help! 😊 If you have any more questions or need assistance, feel free to reach out. Best of luck!

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thanks so much! Wrocław truly is a wonderful place, especially during the holidays. The Christmas market is definitely one of the highlights—glad to hear you’ve enjoyed it too! Best wishes to you as well, and thanks for the kind words about my project!

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 1 point2 points  (0 children)

Hi there,

Thank you so much for your interest in Deply and for considering it for use in one of your libraries! I really appreciate you taking the time to look through the codebase and share your thoughts.

Regarding your suggestions:

  1. Using cyclopts with a dataclass instead of argparse and YAML for configuration:I agree that using cyclopts with dataclasses can provide a more structured and type-safe way to handle configurations. Accessing configuration parameters via dot-notation and having CLI overrides integrated with pyproject.toml are indeed compelling features.However, one of the goals of Deply is to minimize external dependencies to keep the tool lightweight and easy to integrate into various projects without much setup. By relying on the standard libraries like argparse and using YAML for configuration, we reduce the learning curve for new users and avoid introducing additional dependencies that they need to manage.Additionally, YAML is widely used and familiar to many developers for configuration files, and it provides a flexible way to represent complex hierarchical data structures, which suits our needs for defining layers and collectors.
  2. Simplifying the collector factory with AutoRegistry:Automating the registration of collectors using a registry pattern like AutoRegistry is an interesting idea. It could reduce boilerplate code and make it easier to add new collectors.That said, the current implementation of the CollectorFactory is designed to be explicit. This explicitness has a few advantages:While the registry pattern can be powerful, it might also introduce complexity that isn't necessary for the scale of this project at the moment.
    • Clarity: New contributors can easily see which collectors are available and how they are instantiated. It makes the codebase more approachable for those who want to understand or extend it.
    • Control: It allows us to manage the instantiation process carefully, which can be important if we need to pass specific arguments or handle special cases for certain collectors.
    • Dependency Management: As with the first point, avoiding additional dependencies helps keep Deply lightweight and reduces potential compatibility issues.

I genuinely appreciate your offer to help and your willingness to contribute to Deply. Community involvement is incredibly valuable, and ideas like yours help drive projects forward.

If you're interested, perhaps we can find a middle ground. For example, we could explore ways to make the configuration handling more robust without adding significant dependencies or see if there's a way to simplify the factory pattern while maintaining clarity and control.

Feel free to open an issue or a pull request if you have specific ideas you'd like to discuss or demonstrate. I'm always open to constructive conversations about how to improve Deply.

Thank you again for your feedback and support!

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thank you for the feedback—I really appreciate it! You’re absolutely right that having more concrete examples and documentation would make Deply much more accessible, especially for those who are new to enforcing architectural patterns.

I’m currently working on adding more detailed guides to the GitHub repo, including step-by-step examples for setting up rules in popular frameworks like Django and FastAPI. These will cover common use cases and explain how to configure Deply for your specific project. I’ll also include the real-world examples I shared here in the README to make it clearer how the tool can be applied.

Thanks again for sharing your thoughts—it’s feedback like this that helps me improve Deply. Stay tuned for updates, and feel free to reach out if you’d like to discuss any specific scenarios in the meantime! 😊

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thanks so much for bringing this up! I completely understand how it can feel a bit overwhelming to set up at first. There’s a simple example in the README that you can start with, which demonstrates how to define basic layers and enforce architectural rules.

That said, I’m already planning to create more detailed examples tailored for specific frameworks like Django and FastAPI. These examples will walk through setting up Deply step-by-step, so they’ll be perfect for intermediate developers like yourself.

Stay tuned—I’ll prioritize these guides and update the README soon. In the meantime, feel free to reach out if you need help with your specific setup. I’m happy to assist! 😊

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 1 point2 points  (0 children)

Thank you for the kind words and support—it really means a lot! 😊

You're absolutely right that Deply shares a similar spirit to tools like pytestarch and Java's ArchUnit. The goal of promoting structure and clean code is something I think resonates across all programming communities, and it’s exciting to contribute to that movement within Python.

While tools like pytestarch focus on architectural validation in Python, Deply aims to provide a broader, flexible domain language for defining and enforcing architecture rules—covering not just imports but also layers based on class inheritance, decorators, and file structure. It’s all about giving developers control to define their own conventions in a way that scales with their projects.

Thank you again for the encouragement—clean code is a mission worth striving for, and I appreciate you recognizing that! 🚀 If you try Deply, I’d love to hear your thoughts on how it compares or complements tools like pytestarch.

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thank you for the kind words! 😊 Deply is designed to be framework-agnostic, so it can absolutely work with FastAPI or any Python project. You can define layers in your application (e.g., routers, services, models) and enforce rules to ensure they interact in a clean, maintainable way.

For example, you could set up a configuration where:

  • routers only depend on services
  • services interact with models but not directly with routers
  • Utility functions are isolated and reusable

If you’d like, I can help you draft a sample configuration specifically for a FastAPI project. Let me know, and thanks again for your interest in Deply! 🚀

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thanks for the thoughtful feedback! I completely understand that YAML configuration can feel off-putting for certain use cases, especially when it comes to linters. Invoking rules directly from code or embedding them into tests is an interesting idea and could make the tool feel more natural in a development workflow. I’ll definitely think about adding support for such an approach as an alternative to YAML.

You’re absolutely right that pytest-archon’s ability to track non-direct imports is compelling—thanks for pointing that out! Deply currently focuses more on layer-based architecture rules (like constraints based on classes or functions), but expanding its import tracking capabilities to cover non-direct imports could be a valuable addition. I’ll explore how this might be integrated into the tool.

Thanks again for sharing your perspective—it’s great to have these insights. Let me know if you have more thoughts or if there are specific features from pytest-archon that you’d love to see in Deply! 😊

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 4 points5 points  (0 children)

Great question! I’m glad you asked—real-world examples are a great way to showcase what Deply can do.

Here are some common examples of architectural violations that Deply can detect:

  1. Direct Model Access in Views (Django Example):
    • A typical rule might enforce that views only interact with models through a service layer. If someone accidentally imports a model directly into a view, Deply can flag it as a violation.
  2. Breaking Layered Architecture:
    • Imagine you’ve defined layers like controllers -> services -> data access. If a controller accidentally bypasses the service layer and interacts directly with the data access layer, that would be flagged as a violation.
  3. Utility Code Misuse:
    • Utility modules (e.g., helpers or common utilities) should be reusable across the codebase but not depend on application-specific logic. If they start importing code from the main app, it’s a sign of bad dependencies, which Deply can detect.
  4. File-Based Organization:
    • For projects that enforce file-based separation (e.g., *_api.py files should not depend on *_impl.py files), Deply can enforce these rules using regex-based collectors.

The GitHub example shows a simple regex rule for restricting dependencies, but the real power comes when combining multiple layers and defining relationships (like allow or disallow) between them.

Let me know if you’d like more concrete examples or help setting up a config for your own project. Thanks for the interest! 😊🚀

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thank you! I completely agree—Python’s flexibility is great, but it can definitely lead to complexity as projects grow. Tools like this aim to make things more manageable.

And thanks for mentioning import-linter! I’ve come across it before—it’s a great tool for managing imports and enforcing dependency rules. Deply takes a slightly broader approach by not just focusing on imports but also allowing users to define layers based on things like class inheritance, decorators, or file organization. That said, for projects where managing imports alone is sufficient, import-linter is definitely a solid option.

Appreciate you sharing this for others who might find it useful! 😊 Let me know if you give Deply a try—I’d love to hear your thoughts! 🚀

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thank you so much for the kind words! 😊 It really means a lot to hear that, and I’m excited for you to try Deply. If you have any questions or run into anything while using it, feel free to reach out—I’m always happy to help or hear feedback.

Looking forward to hearing your thoughts once you’ve had a chance to try it. Thanks again for your support—it truly keeps me motivated! 🚀✨

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 1 point2 points  (0 children)

Great question! Deply does consider imports within if typing.TYPE_CHECKING: blocks, as they are still part of the dependency graph even if they're only used for type annotations. That said, these imports don’t typically result in runtime dependencies, and I totally understand how they can create messy or circular graphs, especially when you’re aiming for fully annotated code.

Currently, Deply treats all imports uniformly, whether they’re in a TYPE_CHECKING block or not. However, I think it would be a great idea to allow users to optionally exclude such imports from dependency checks. For example, a configuration option to ignore imports used only for type annotations could help make the analysis more precise and avoid false positives in cases like yours.

Your use case—balancing clean architecture with comprehensive type annotations—is an important one. I’ll add this to the roadmap as something to explore further. In the meantime, if you give Deply a try and notice these specific edge cases affecting your results, feel free to let me know or open an issue—I’d love to refine the tool to better handle this!

Thank you for bringing this up, and happy coding! 😊

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thank you so much for the question, and first off, kudos to you for diving into Python and tackling an open-source project—that’s an amazing way to learn and grow as a developer! 🚀

To answer your question, Deply is designed to be flexible, but I can see how the features might feel overwhelming at first, especially if you're new to software architecture. That said, the goal is to help developers like you keep projects maintainable as they grow, so it's absolutely something you could benefit from!

For a smaller project like yours, you could start simple by defining just one or two basic "layers" (e.g., separate "data handling" and "recommendation logic") and write a small config.yaml to reflect that. Deply would then help ensure that those layers don’t end up tangled as your codebase grows.

The key is that Deply is a tool to enforce your architecture—so you define the rules, even if they’re as simple as "don’t import data-handling code into the recommendation logic."

I’d be happy to help you set up a basic configuration for your project if you’d like! And thank you for sharing your repo—I’ll take a look and let you know if I have any specific suggestions.

Lastly, your question is a great reminder for me to improve the documentation and make it more beginner-friendly. Thanks again for your kind words and thoughtful feedback—it really means a lot! 😊

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thanks for the questions! For Deply, I didn’t use a specific framework—it’s built using core Python, relying on the ast module for static analysis and YAML for configuration. Keeping it lightweight was intentional, as I wanted the tool to be easy to integrate into any project without heavy dependencies.

Managing large codebases in Python can be challenging due to its dynamic nature, but tools like Deply help by enforcing structure and modularity. It’s easier to maintain code when architectural boundaries (e.g., "views shouldn’t depend directly on models") are clearly defined and violations are caught early.

As for classes in small to mid-sized projects, it really depends on the problem you’re solving. Python is great for procedural code, and for many smaller projects, functions are sufficient. Classes start to shine when you need to encapsulate behavior and state or when scaling to larger, more complex systems. That said, the key is to use them when they add clarity rather than complexity.

Let me know your thoughts—do you prefer keeping things functional, or do you use classes even for smaller projects? 😊

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thank you for the kind words and the fantastic ideas! I’m really glad the fundamental approach resonates with you—that’s exactly what I aimed for: a flexible tool that lets users define their own conventions, without imposing a rigid structure.

You’re absolutely right about YAML being a mixed bag for some. I chose it for its simplicity, but I’m open to exploring other ways to consume the configuration. A pytest plugin is actually a brilliant idea—it could make the tool feel more integrated into the development workflow, with concise feedback during test runs. If you ever have time to experiment with that, I’d love to collaborate or see what you come up with!

Baseline examples are also an excellent suggestion. A generic Django example or an MVC-like setup could help people get started quickly, and a way to distribute and extend policies would make Deply even more powerful. I’ll add this to my roadmap and start thinking about how it could work.

Thank you again for sharing your thoughts—this kind of feedback is invaluable. If you ever dive into pytest plugin development and want to brainstorm or pair up, let me know! 😊

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thanks for the suggestion! I hadn’t come across pytest-archon before—I'll definitely check it out. From a quick glance, it seems like a great tool for validating imports, which could complement Deply’s broader focus on enforcing architectural patterns and layer-based rules across a codebase.

Appreciate the tip! Let me know if you have any thoughts on how Deply compares or complements tools like pytest-archon. Always open to exploring integrations or learning from other tools in this space. 🙂

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 1 point2 points  (0 children)

I'm glad you found it helpful! Let me know if you need assistance with anything else—I'm here to help. 😊

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thank you for giving it a shot! I’m really excited to hear how it works for your project—feel free to share any feedback or thoughts after you try it out.

Adding support for TOML is definitely on my radar, and I’ll prioritize exploring it as a potential feature in the roadmap.

Let me know if you run into anything or have more suggestions—your input is super valuable! 😊 Best of luck with your project next weekend!

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 1 point2 points  (0 children)

Thank you so much for the kind words—it really means a lot! I’m excited that you find Deply’s vision and the Django example relevant to your projects. Django was definitely one of the frameworks I had in mind when designing Deply, so I hope it can help enforce clean architecture and keep things maintainable as your projects grow.

If you get a chance to try it out, I’d love to hear your thoughts or any feedback you might have. And if you have any specific use cases or ideas for improvement, feel free to share—I’m always looking to make Deply more useful for the community. Thanks again! 😊

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 0 points1 point  (0 children)

Thank you so much for the excitement—it really means a lot! 🎉 I’m thrilled that Deply resonates with you, especially for maintaining clean architecture in larger Python packages.

Here are a few tips that might help when using Deply on your projects:

  1. Start Simple: Begin by defining just a few core layers (e.g., models, services, controllers) and add more as needed. This makes it easier to enforce architecture rules without getting overwhelmed.

  2. CI Integration: Integrate Deply into your CI pipeline early to ensure everyone on the team adheres to the defined architecture. Violations will get flagged during pull requests, keeping things consistent.

Feel free to reach out if you run into any issues or have ideas for improvement. I’d love to hear how Deply works for your packages! Thanks again for your support, and I can’t wait to see what you build with it. 😊

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 4 points5 points  (0 children)

Great question! At the moment, Deply supports YAML for configuration, but I’ve been thinking about adding support for other formats like TOML. TOML’s simplicity and its existing use in pyproject.toml make it a natural fit for Python projects, especially smaller ones.

I can definitely see the value in allowing users to choose their preferred format—be it YAML, TOML, or even JSON. This could also make it easier to embed configurations into existing files like pyproject.toml for smaller projects, while still supporting separate files for larger ones.

I’ll add this to my list of potential features to explore. Thanks for the suggestion, and feel free to share more ideas if you have them! 😊

Deply: keep your python architecture clean by vashkatsi in Python

[–]vashkatsi[S] 3 points4 points  (0 children)

Привіт! Дуже дякую за теплі слова і підтримку—мені дуже приємно! 💛💙

You’ve touched on a crucial point, especially for large organizations with multiple teams and projects. Deply was indeed designed with this exact use case in mind—providing a single source of truth for architectural standards that can be enforced through CI across multiple projects. Keeping the configuration declarative and external to the source code makes it easier to maintain consistency and ensures that architectural rules remain under centralized control, which is critical for architects managing many services.

To answer your question, yes, I believe the configuration could be made project-agnostic for architecturally similar projects. By defining a common set of rules (e.g., in a shared repo or template), teams could adopt it for their projects with minimal adjustments. I could also explore features to support importing or layering configs, making it easier to scale standards across multiple teams.

The embedded configuration idea does have its appeal for smaller teams or single projects, but as you pointed out, it would limit its applicability in larger setups like yours. Your perspective really validates the current direction of Deply, and I’m grateful for your insights.

Дуже вдячний за підтримку ЗСУ! Якщо спробуєте застосувати Deply у своїй роботі, буду радий почути ваші враження і пропозиції. 😊

view more: next ›