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

Lock dependencies to minimal versions #2310

Closed
whitequark opened this issue Oct 11, 2023 · 4 comments · Fixed by #2327
Closed

Lock dependencies to minimal versions #2310

whitequark opened this issue Oct 11, 2023 · 4 comments · Fixed by #2327
Labels
⭐ enhancement Improvements for existing features

Comments

@whitequark
Copy link
Contributor

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

When shipping software that depends on ranges of versions of other software, it is often the case that everyone developing the software installs the latest versions of the dependencies, and inadvertently introduces uses of functionality not included in the minimal version specified in the pyproject.toml file.

Describe the solution you'd like

A mode for pdm lock that inverts the version resolution algorithm so that the lowest versions are picked for each direct dependency.

Other package management systems include similar functionality, e.g. cargo -Z minimal-versions and cargo -Z direct-minimal-versions. Here I am only asking for the second one, which I think is easier to implement and is more useful for my use case.

@whitequark whitequark added the ⭐ enhancement Improvements for existing features label Oct 11, 2023
whitequark added a commit to whitequark/glasgow that referenced this issue Oct 11, 2023
This allows us to have a reproducible source of truth for the versions
that our software should definitely work on, and also have a way (until
pdm-project/pdm#2310 is resolved) to ensure that our lower version
constraint in `pyproject.toml` still works with latest source code.
whitequark added a commit to whitequark/glasgow that referenced this issue Oct 11, 2023
This allows us to have a reproducible source of truth for the versions
that our software should definitely work on, and also have a way (until
pdm-project/pdm#2310 is resolved) to ensure that our lower version
constraint in `pyproject.toml` still works with latest source code.
whitequark added a commit to whitequark/glasgow that referenced this issue Oct 11, 2023
This allows us to have a reproducible source of truth for the versions
that our software should definitely work on, and also have a way (until
pdm-project/pdm#2310 is resolved) to ensure that our lower version
constraint in `pyproject.toml` still works with latest source code.
whitequark added a commit to whitequark/glasgow that referenced this issue Oct 11, 2023
This allows us to have a reproducible source of truth for the versions
that our software should definitely work on, and also have a way (until
pdm-project/pdm#2310 is resolved) to ensure that our lower version
constraint in `pyproject.toml` still works with latest source code.
whitequark added a commit to whitequark/glasgow that referenced this issue Oct 11, 2023
This allows us to have a reproducible source of truth for the versions
that our software should definitely work on, and also have a way (until
pdm-project/pdm#2310 is resolved) to ensure that our lower version
constraint in `pyproject.toml` still works with latest source code.
whitequark added a commit to whitequark/glasgow that referenced this issue Oct 11, 2023
This allows us to have a reproducible source of truth for the versions
that our software should definitely work on, and also have a way (until
pdm-project/pdm#2310 is resolved) to ensure that our lower version
constraint in `pyproject.toml` still works with latest source code.
whitequark added a commit to whitequark/glasgow that referenced this issue Oct 11, 2023
This allows us to have a reproducible source of truth for the versions
that our software should definitely work on, and also have a way (until
pdm-project/pdm#2310 is resolved) to ensure that our lower version
constraint in `pyproject.toml` still works with latest source code.
@pawamoy
Copy link
Contributor

pawamoy commented Oct 11, 2023

Also see discussion in #2033.

@whitequark
Copy link
Contributor Author

To add more context: the alternative to this is a manually maintained lockfile, which is very not fun to do.

whitequark added a commit to whitequark/glasgow that referenced this issue Oct 21, 2023
This allows us to have a reproducible source of truth for the versions
that our software should definitely work on, and also have a way (until
pdm-project/pdm#2310 is resolved) to ensure that our lower version
constraint in `pyproject.toml` still works with latest source code.
@whitequark
Copy link
Contributor Author

@frostming Oh wow!!! You're incredible. Thank you so much. I'll get on to testing this right away, and will likely use the feature on all of my projects of any significance.

@whitequark
Copy link
Contributor Author

@frostming I have went ahead and used this feature in the Glasgow Interface Explorer software stack. You can see how it's done in GlasgowEmbedded/glasgow#463. It appears to work perfectly well, to the point where I went ahead and switched our CI to use head PDM version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⭐ enhancement Improvements for existing features
Projects
None yet
2 participants