-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New contract type: private_modules #159
Comments
You can do what you want with a custom contract. Here's one which allows configuring which submodules can be imported, that is this enforces that only public submodules can be imported.
And usage (place the class above in import_contracts.py):
Now, if myproject.othermodule imports myproject.send_email.implementation that's a violation, but if it imports myproject.send_email.utils that is ok. It should be relatively straightforward to turn this the other way around - that you list the private submodules, and all other imports are fine. I'd like to have this both ways in, that is you can configure public submodules or private submodules with standard contracts. Bonus points if the module itself can contain the contract configuration. This way you could just open myproject/send_email/import_contract.cfg and see how the module can be used, and then import-linter would enforce the contract. |
Thanks for including! To clarify, this ticket is about a general contract that would enforce a convention we use in our internal code base where modules prepended with an underscore should only be accessible within that same subpackage. The contract would then cover the whole code base and check this convention is being followed (rather than needing to list specific modules in a contract), something like:
|
A contract which enforces 'private' modules using underscore prefixes.
For example, a module named _foo.py should not be imported directly except by its direct parent package.
The text was updated successfully, but these errors were encountered: