Optionally install minimum version of dependencies

[pohlt]

How about pdm offers an optional mode where it installs the minimum version of all dependencies?

I know that this might sound weird, but it does have some advantages: more reproducible builds, works better with CalVer, you actually tested the code with the dependency versions others will use

This could be an option in the project file and/or a command line switch during installation.

This idea is neither new nor mine. I actually saw it as the default mode in Atlas, a package cloner for nim.

[pawamoy]

I would be interested in this as well. I think you can use an extra for this (and/or the ability to lock single groups into different lock files), but you'd have to specify and pin all transitive dependencies not just direct ones, which is a bit cumbersome.

[frostming]

The same idea has been expressed in #906

I don't think it is that useful in Python's packaging system. For example, you will probably get foo==0.0.1 for a requirement foo and it might be a package developed on Python 2.4 and can never run on the latest Python versions. But this information can't be acquired from the package metadata and the resolver doesn't know either. So there will be a big chance to get a lockfile not working at all.

[pawamoy]

If foo is in your own project (direct dep), you can then add a lower bound, and continue on other problematic dependencies until you get a working lock file (and passing tests). That's kinda the idea behind it: find the lowest versions that work with your current code.

If foo is in another library you depend on (transitive dep), it's OK, you can still add the lower bound yourself, in your own project (and you should if foo 0.0.1 is not supported by your current code anyway).

[pohlt]

This topic has been discussed in the pip context in detail for two and a half years, e.g., how to deal with direct and transitive dependencies.

I agree that going minimal with both direct and transitive dependencies will most likely leave you with a broken installation, a mixed approach might work: minimum version for direct dependencies (as the author of the package you have control over this) and maximum version for transitive dependencies. There will be corner cases for sure (e.g. dependencies which are both direct and transitive), but I think they can be handled as well.

For me, the use case of such a functionality would be to find out if the minimum versions I have chosen actually work.

[pawamoy]

I'd say that you have control even over transitive dependencies: the control to narrow the accepted versions. In a happy world that would not be needed though, since each package would make sure its lowest accepted versions are actually supported 🙂

[pohlt]

@pawamoy Can you add a lower or upper bound for a transitive dependency without making it a direct dependency of your own package?

I agree, we have sort of a 🐔/🥚 problem: Since lower bounds are often broken (or at least untested), we struggle with testing the lower bounds in our own packages.

[pawamoy]

@pohlt You can't! But I think that's OK to make it a direct dependency, since it's already a transitive one. You'd have to regularly check (manually or automatically) that it's actually a transitive dependency though, to remove it once it's not anymore. And some tools might complain that you make it a direct dependency while not using it in your own code directly. So I definitely see the added trouble. Therefore yeah, the mixed approach could be a good start at least.

[pohlt]

The mixed approach might work to break this cycle of untested lower bounds and once this topic gets more traction (will it ever?) and everybody fixes their lower bounds (haha!) we can use the minimum bounds for all dependencies. 😉

@frostming How much effort would it be to add a command line switch to test this functionality on a feature branch (without any overhead like documentation or tests)? I'm happy to give it a spin once it's there and later on contribute docs and tests.

[frostming]

Just need to modify the PackageFinder._sort_key to reverse the version order to get this work. But we need to pass the names of requested dependencies to PackageFinder, the only matter is how to make this clean.

[pawamoy]

Formal issue opened at #2310.

[whitequark]

And it has been implemented!