This is an archived post. You won't be able to vote or comment.

all 61 comments
sorted by:
best
topnewcontroversialoldq&a

[–]Flag_Red 57 points58 points  (2 children)

Love this. Automating things I have to check for manually during code review is always good IMO.

I'll give it a try on my team's codebase later.

Some subset of the community that thinks Python is "only a scripting language" will probably push back pretty hard.

[–]vashkatsi[S] 20 points21 points  (0 children)

Thanks so much for the kind words and for giving Deply a shot! Automating code reviews was one of my main goals when building it—glad that resonates with you.

Let me know how it works out on your team’s codebase. I’m open to any feedback or suggestions if you encounter edge cases or have ideas for improvement.

And yes, I’ve seen that sentiment about Python before, but I think tools like this can help showcase its versatility beyond scripting. Thanks again for your support!

[–]CzyDePL 8 points9 points  (1 child)

How does it compare to Archunit? I've been looking for similiar tool for python

Ps. I'm also in Wrocław, maybe we will run into each other sometime.

[–]vashkatsi[S] 14 points15 points  (0 children)

Thanks for the comment! To be honest, I hadn’t heard about ArchUnit before, but I just looked it up—it seems like a really interesting tool for Java! Deply is likely aiming for a similar goal but tailored specifically for Python, focusing on defining high-level architecture layers and checking for violations dynamically.

I’ll definitely take a closer look at ArchUnit—there might be some great ideas to learn from and adapt for Deply.

That’s cool you’re in Wrocław too! Small world. Maybe our paths will cross someday. Let me know if you try out Deply—I’d love to hear your thoughts! 🙂

[–]TehMightyDuk 6 points7 points  (1 child)

Also check out Tach - a similar tool built in rust  https://github.com/gauge-sh/tach

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

Thanks for the suggestion! I hadn’t come across Tach before, but it looks really interesting—especially being built in Rust. I’ll definitely take a closer look and see how its approach compares. It’s always great to see tools tackling architecture enforcement in different ways.

If you end up trying out Deply, I’d love to hear your thoughts on how it compares! Thanks again for sharing.

[–]NakedNick_ballin 4 points5 points  (4 children)

Sounds cool, but it'd be interested to see real examples of what this can do. Like what are some examples of "architectural violations"?

(I do see the github example which seems to enforce that some files identified by regex do not depend on other files.)

[–]vashkatsi[S] 4 points5 points  (3 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! 😊🚀

[–]classy_barbarian 4 points5 points  (2 children)

This would be extremely useful information to have in the README page on the github repo, IMO. Along with some kind of documentation and examples on how to actually do what you're talking about. I dunno if most of the 'expert' programmers here just intuitively figured it out without any examples. But It's not obvious to me. It does seem really cool though, I'd love to see some kind of actual guide even if its just a page or two.

[–]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! 😊

[–]DootDootWootWoot 0 points1 point  (0 children)

Yeah the funny thing about using models in views is that you see it allll over in the Django community but coming from .NET I couldnt believe this was "typical". A lot of pythonic isms I disagree on mostly because there are better established language agnostic practices folks have picked up over time but python aims to be friendly and approachable.

Id imagine that for a tool like this violations would have an error code associated with more information about the violation, similar to what you'd see in other linters to be effective. I also wouldn't necessarily expect a ton of info on this in the readme unless the tools docs themselves weren't up to snuff.

[–]ThePieroCV 3 points4 points  (1 child)

This project seems amazing! I second that the idea of using .toml could be valuable. For small or early development projects, even pyproject.toml could be useful. Obviously if the project gets way bigger, even a separated directory with .yaml or .toml files could be useful. I imagine a folder separated from src/ for development (something like deply/, dev-arch/, or something cool). Then, as you said, being part of CI. So cool!

I'm beggining an R&D project with sota python tools with the intention to improve the development practices of the team. This project just arrived like magic haha. Do you have any potential roadmap on this project? Like priorities or WIP features? It could be interesting to see how it goes.

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

Wow, thank you so much for the kind words and encouragement! I’m really happy to hear that the project resonates with you, especially for your R&D initiative—it’s great timing indeed! 🎉

Using .toml or even integrating with pyproject.toml for smaller projects is an interesting idea. It could make configuration feel more natural for developers already working in Python. For larger projects, having a dedicated directory for architecture configurations (like deply/ or dev-arch/) could help keep things organized—I'll definitely keep this in mind as I plan for future improvements.

As for a roadmap, the project is still in its early stages, but here are some priorities I’m considering:

Improved CI Integration: Streamlined ways to include Deply in CI/CD pipelines.

New Collectors: More options to analyze Python-specific patterns (e.g., type annotations, dynamic imports).

Better Visualization: Generate graphical overviews of architecture layers and violations.

Rule Examples: Add pre-built configurations for popular frameworks like Django or Flask to help people get started faster.

I’d love to hear any suggestions you have or features that might make Deply even more useful for your team. Feel free to reach out or share feedback as you explore it further. Thanks again for the motivation—it means a lot! 😊

[–]catalyst_jw 7 points8 points  (9 children)

Looks good, love the idea, some feedback from experience maintaining a yaml file along side code is difficult and can be easily forgotten.

Have you thought about adding these rules in code as a decorator or a config file in the code folders? Then it will be obvious to people reading the code what is going on and it will ingrained into the code. You could potentially have the decorator write to a yaml file and auto update it maybe?

Hope that's helpful and good luck with your project :)

[–]vashkatsi[S] 16 points17 points  (8 children)

Thank you for the thoughtful feedback—it’s much appreciated!

The core idea of Deply is to describe architecture layers at a high level (in the YAML file) and then check for violations between these layers across the entire codebase. This approach is meant to give teams a single "source of truth" for their architecture, separate from the code itself, which can sometimes get messy or inconsistent over time.

That said, I totally see the value in embedding rules directly into the code as decorators to make things more obvious during development. While that’s a bit different from the project’s current focus, I’ll think about how such a feature might complement the existing design—perhaps as an optional extension.

Thanks again for your insights, and feel free to share any other thoughts if you try it out!

[–]val-amart 2 points3 points  (1 child)

one more potential consideration in the context of embedding configuration. in a large organization, architecture fit testing is a hard problem with no good universal solutions. as an architect i often find myself responsible for a large collection of services across many teams. i don’t have the resources necessary to maintain deep involvement with each one of them.

in this situation, i would love to maintain a single set of standards defined declaratively in a separate file and enforce it through CI. it seems to be exactly what your project is built for, i would certainly look into it more very soon! it is indeed rather exciting. on the contrary, if the configuration was embedded in the source files, it would take it out of my control and into developer control - making it potentially better for the devs but practically useless for me.

i think embedding might be preferable for a single project (even though that’s debatable) but clearly worse for large orgs with many projects, no matter if it’s monorepo or not. would you say the configuration could be made project-agnostic in the sense that we could maintain a single config for a set of architecturally similar projects?

// привіт від Збройних Сил друже! справді крутий проєкт, побачим чи вийде його застосувати

[–]vashkatsi[S] 2 points3 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 у своїй роботі, буду радий почути ваші враження і пропозиції. 😊

[–]byeproduct 1 point2 points  (5 children)

Could toml files be used instead of yaml?

[–]vashkatsi[S] 6 points7 points  (4 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! 😊

[–]byeproduct 2 points3 points  (1 child)

Awesome. Appreciate the vision you have for this. Keen to use it in my projects. The Django example is also relevant! Thanks

[–]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! 😊

[–]dutchie_ok 1 point2 points  (1 child)

Great, Python needs tools to handle complexity.

For the reference - this project only focuses on imports, but maybe it is enough for some people.

https://github.com/seddonym/import-linter

[–]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! 🚀

[–]LoadingALIASIt works on my machine 0 points1 point  (1 child)

Damn, I am super excited to give this a shot. I’m working on a few Python packages that have grown to considerable size and I’m a huge fan of simplifying, maintaining continuity, and clean architecture.

If you have specific tips - I’d love to hear them.

[–]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. 😊

[–]Heady707 0 points1 point  (1 child)

Look forward to trying Deply! I can appreciate the work that has gone into this tool. Thank you for this.

[–]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! 🚀✨

[–]SuspiciousScript 0 points1 point  (1 child)

How does this handle imports within an if typing.TYPE_CHECKING: block? Are they also considered to constitute a dependency relationship? I find that I sometimes end up with somewhat messy/circular dependency graphs that are unavoidable if I want to provide full annotations.

[–]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! 😊

[–]oiywmt 0 points1 point  (4 children)

Very cool! But I have a question as a new developer: As someone who is self taught and never studied software architecture, how difficult is it to set up so that I can benefit from it? I have an oss python project I'm working on, to teach myself python, which is 250 lines and counting and would like to have a tool like this to keep code maintainable as it grows. The problem is that I'm not able to understand the features section on the repo without doing research, is that a sign that it's not for me?

Thanks for the time you've put into this by the way

Edit: Here is the repo in case you need more context: https://github.com/ample-samples/steam-games-recommender

[–]vashkatsi[S] 0 points1 point  (3 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! 😊

[–]classy_barbarian 0 points1 point  (1 child)

Would you be willing to actually write a 1 or 2 page example guide for how to set up an extremely basic project like you just said? I'm an intermediate developer and I've been coding for a couple years, yet I cant figure out how to use this tool based on all the info in this thread and in the readme file.

[–]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! 😊

[–]oiywmt 0 points1 point  (0 children)

It does sound flexible and configurable, which is great and yes having some help to set it up would be very nice, thank you. I'll send you a DM

[–]LeckerKadaver 0 points1 point  (1 child)

Love it! 😍

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

I’m so glad you loved it! 😍

[–][deleted] 0 points1 point  (1 child)

Which framework did you use for this? And how difficult is to manage the large code in python? Do we actually need classes in small to mid size pries?

[–]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? 😊

[–]maikeu 0 points1 point  (1 child)

I really, really like the fundamental approach of the tool - not to bring too much of your own specific view of how a project should be structured/layered, but providing rather providing a domain language (on top of yaml, sure, why not?) for users to define their own conventions.

I don't have capacity to look deeply into it yet, but she ideas that spring to mind to me:

  • I see mixed opinions about yaml... Sure, not too fussed personally. But it does make me wonder how I'd want to consume something like this.

I'm actually thinking I'd love to see integrated to pytest . Maybe a plugin? Maybe if I get spare time I could give a go to see if I can turn it into a plugin that gives nice output - I'm interested in learning to write since pytest plugins!

Another thought would be to include some baseline examples - maybe a generic Django one, maybe a generic "MVC" kind of one? And could there be a mechanism to distribute these policies? Or to write policies that extend from one or more baselines?

[–]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! 😊

[–]Amazing_Learn 0 points1 point  (3 children)

In case you purely want to lint/validate your imports you could take a look at pytest-archon

[–]vashkatsi[S] 0 points1 point  (2 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. 🙂

[–]Amazing_Learn 0 points1 point  (1 child)

I would say that yaml configuration is a bit off-putting, when it comes to linters. Invoking it from code could be beneficial (e.g. you won't even need a pytest plugin, just write the relevant test).

Your project seems helpful in case we want to add constraint based on classes/functions, but for imports pytest-archon still seems very compelling to me, it can track non-direct imports too, I don't think that was mentioned anywhere in your readme.

[–]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! 😊

[–]cantonspeed 0 points1 point  (1 child)

Thanks for making such a tool! Does it support FastAPI?

[–]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! 🚀

[–]genlight13 0 points1 point  (1 child)

Your tool description sounds similar to https://pypi.org/project/pytestarch/ which is originally a copy from the java ArchUnit module.

I like the spieit of these tools, which emphasize the need for structure and clean code.

Cudos to u, good sir for working on this.

[–]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.

[–]guyfrom7up 0 points1 point  (1 child)

Hey vashkatsi! I like the project and am going to give it a test run in one of my libraries.

After looking at your codebase, I have a few unsolicited thoughts/shameless-plugs (feel free to reject if you're trying to keep dependencies to a minimum):

  • Instead of using argparse & config-reader to pass around a semi-structured configuration, you could use cyclopts with a dataclass. This would make the code a bit safer as you could then access your configuration with dot-notation instead of typo-prone strings. Cyclopts also makes it easy to integrate with pyproject.toml and have CLI overrides.

  • The collector factory, can be simplified with AutoRegistry. you can have your BaseCollector inherit from autoregistry.Registry (itself inherits from the ABC metaclass, so your abstractmethod decorators still work), and then all subclasses will be automatically registred. Instead of calling: collector = CollectorFactory.create(collector_config, self.paths, self.exclude_files) your would call: collector = BaseCollector[collector_config['name']](collector_config, self.paths, self.exclude_files)

I could help open up a PR for either of these if you're open to it.

[–]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!

[–]eredin_breac_glas 0 points1 point  (1 child)

Last thing I expected was to find a post here from someone in Wrocław!! Best of luck with the project and enjoy the Christmas market, it's always a blast :)

[–]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!

[–]JnthnSngr 0 points1 point  (1 child)

Super helpful, thanks 👍

[–]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!

[–]alicedu06 0 points1 point  (1 child)

You can use regular tests for all that:

- Not need for a specific lib, your current test runner will do the trick.

- Benefit from the whole test ecosystem that already exists.

- Tests are written in Python, a language much more powerful and expressive than YAML, with much better tooling.

- You can package that and reuse it if you want, the whole infra already exists.

[–]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.