Our great sponsors
-
import-linter
Import Linter allows you to define and enforce rules for the internal and external imports within your Python project.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Before clicking on this, I expected to see import-linter [0] which achieves something very similar but with, in my opinion, a bit less magic. Another solution in a similar spirit is Pants [1], though this is actually a build system which allows you to constrain dependencies between different artifacts (e.g. which modules are allowed to depend on which modules).
To Sourcery's credit, their product looks much more in the realm of "developer experience" -- closer to Copilot (or what I understand of it) than to import-linter. Props to them for at least having a page about security [2] and building a solution which doesn't inherently require all of your source code to be shared with a vendor's server.
[0] https://github.com/seddonym/import-linter
[1] https://www.pantsbuild.org/
[2] https://docs.sourcery.ai/Product/Permissions-and-Security/
Before clicking on this, I expected to see import-linter [0] which achieves something very similar but with, in my opinion, a bit less magic. Another solution in a similar spirit is Pants [1], though this is actually a build system which allows you to constrain dependencies between different artifacts (e.g. which modules are allowed to depend on which modules).
To Sourcery's credit, their product looks much more in the realm of "developer experience" -- closer to Copilot (or what I understand of it) than to import-linter. Props to them for at least having a page about security [2] and building a solution which doesn't inherently require all of your source code to be shared with a vendor's server.
[0] https://github.com/seddonym/import-linter
[1] https://www.pantsbuild.org/
[2] https://docs.sourcery.ai/Product/Permissions-and-Security/
Yes, according to the way I did it. You could put DRF serializers and Pydantic schema into the same file and call that "serializers.py", or you could just use DRF for incoming form validation.
Similarly, you could collapse "selectors.py" into "services.py". I put read-only operations into "selectors.py" and write operations into "services.py", but you don't have to. I got that idea from this styleguide: https://github.com/HackSoftware/Django-Styleguide which is in the Appendix of the Django Domain API docs.
Related posts
- Pants 2.8: Support for Autoflake & Pyupgrade, Docker publishing, Golang, and Google Cloud Functions
- Kraken Technologies: How we organise our large Python monolith
- Pants 2: The ergonomic build system
- Is it possible pickle a function with its dependencies?
- Sanity check of my decision for "Iterative AI" (DVC, MLEM, CML) pipeline over Azure ML