Add support for setuptools PEP-621
fpgmaas opened this issue · 4 comments
I'd be happy to take a stab at this one.
Sounds good to me! One issue for this one; how do we deal with development dependencies? As far as I know, there is no agreed upon method to differentiate optional from development dependencies. See also this section of PEP-621.
Should we add a CLI command that allows the user to specify which entries under [project.optional-dependencies] are development dependencies?
e.g.
[project.optional-dependencies]
develop = ["pytest", "pytest-cov"]
rest = ["docutils>=0.3", "pack ==1.1, ==1.3"]
deptry . --dependencies-dev-keys develop
And have (dev, develop) as defaults?
Sounds good to me! One issue for this one; how do we deal with development dependencies? As far as I know, there is no agreed upon method to differentiate optional from development dependencies. See also this section of PEP-621.
I've had some thoughts about this, and I think your proposal would make sense. Because the PEP itself doesn't specify anything related to development dependencies, several projects using packaging tools that implement PEP 621 will use optional dependencies to define their development dependencies.
Although there is one point that makes me think that adding an option to declare development groups could require more discussions. Some tools following PEP 621 (like PDM), provide another custom layer to define all development dependencies, as using optional-dependencies will basically create an extra that is installable using things like pip install package[dev], which may not be the desirable output for libraries. Other projects not using PDM also sometimes declare their development dependencies into separate requirements.txt, and not into pyproject.toml files, while using PEP 621 for the library dependencies (and potential extras).
This really makes me think that deptry should possibly be more flexible about how it is able to understand dependencies, and instead of selecting only one "dependency specification" type (PDM, PEP 621, poetry, requirements.txt, ...) should be flexible enough as to let the users use multiple sources for one invocation of deptry (for instance, one project could define its dependencies using PEP 621 format for the library itself, but use a requirements-dev.txt files for development dependencies).
But adding such flexibility is not strictly tied to this issue (although a bit), so I'd still be up for implementing PEP 621 support (even if basic) as a way to kickstart the work, then start thinking about adding more flexibility to how deptry discovers dependencies, keeping in mind the different options that users could want depending on the diverse ways that projects use to define all their dependencies.
Since support for PEP 621 itself is implemented, and #168 has been created to track further improvements that could be made, let's close this issue.