Skip to content
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

Explicitly specify modules to consider as first party ones #247

Closed
mkniewallner opened this issue Dec 29, 2022 · 2 comments · Fixed by #257
Closed

Explicitly specify modules to consider as first party ones #247

mkniewallner opened this issue Dec 29, 2022 · 2 comments · Fixed by #257
Assignees
Labels
enhancement New feature or request

Comments

@mkniewallner
Copy link
Collaborator

mkniewallner commented Dec 29, 2022

Is your feature request related to a problem? Please describe.

deptry currently relies on the presence on __init__.py files in the directories present in the root directory to determine if a module is a first party one or not.

This covers most usages of the tool, but there are situations where __init__.py is not used at all, as it's not something that is required anymore since PEP 420.

This is the case of well known projects like Poetry and PDM, for instance.

Additionally, some projects might mangle with PYTHONPATH to make modules importable as if they are first party ones, even if they are located in a sub-directory.

Describe the solution you would like

Providing the ability to explicitly specify a list of known first party modules, additionally to what deptry will automatically guess, may help covering those use cases. This is something that isort implements through known_first_party parameter, for instance.

@mkniewallner mkniewallner added the enhancement New feature or request label Dec 29, 2022
@mkniewallner
Copy link
Collaborator Author

Creating this issue makes me think that we could maybe also implement something similar to known_third_party, where instead of having a list, we would have a mapping between a dependency name and its Python module name(s) (which would mostly be required in case they don't match).

This could enable a way to run deptry without the need to have access to the virtual environment, at the cost of having a complex mapping to maintain, but maybe this is something that some users could be interested in? Tell me what you think @fpgmaas, I'd be happy to open another issue for this if you think this could be useful.

@mkniewallner mkniewallner self-assigned this Dec 30, 2022
@fpgmaas
Copy link
Owner

fpgmaas commented Dec 30, 2022

On the known first party argument; this definitely seems useful to me, agree that this would be a good addition.

On the known third party argument; I think the cost of maintaining this mapping would be quite high, and also is quite prone to user-error; it would need to be updated anytime a dependency is added. I doubt if anyone would actually use this functionality if we add it. Maybe we can/should wait until an issue is raised that would be solved by adding this functionality?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants