-
-
Notifications
You must be signed in to change notification settings - Fork 395
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
Pin version of packaging and other essential dependencies in PDM #1558
Comments
I disagree. It's true that PDM is more an app than a library, but pinning dependencies brings more problems than it solves. I recently started developing a PDM plugin, so my project depends on PDM, and I definitely do not want to be restricted by pins in PDM's dependencies. Packages incompatibilities can always be solved on the final user side, using constraints for example. On the contrary, locking dependencies gives no alternative to downstream users. Just my opinion! |
@pawamoy The whole reason we use PDM is so that we can have reproducible builds, without having unexpected dependency updates breaking us, while still being able to iterate quickly and update dependencies when we need to. With PDM itself not having pinned dependencies, we lose that ability; updates to PDM or its dependencies can make our builds fail when there have been no changes on our side. Of course, having proper support for lockfiles in the Python packaging ecosystem would address this, in which you could have a locked set of dependencies for usage as an application, while loose dependencies when used as a library, just as PDM allows us to do for packages managed by PDM. Unfortunately, there's a bootstrapping problem when installing PDM itself. One possible way to work around this would be to have two published PDM packages; one with pinned dependencies for use as an application, and one with loose dependencies for use as a library. |
Another option is to have an optional extra in PDM that provides the pins ( |
Agree with @pawamoy you can easily exclude a broken dependency version by
I don't think it is a good idea, this will increase the overall burden for the maintainers. They must update the dependencies very carefully and do full tests before publishing. Every broken change of any package may require them to upload a new release of the pinned version. |
Also, note that #1554 and #1556 are different from pypa/packaging#629, they are not regression issues but breaking changes that remove deprecated behaviors. As a library keeps evolving it will introduce breaking changes in an expected and well-noticed manner. If you are still relying on old behaviors you have to use older versions. |
In my environment, some tools are installed using pipx, and one of those is PDM. The occasional breakage due to an incompatible change in a library is not the most pleasant experience. But I can live with it. That each setup has a slightly different set of installed dependencies is what I want to avoid using PDM. Is there an equivalent to where a pdm.lock file can be provided so that every installation has the same set of dependencies inside my organization? |
You can run |
Or simply |
I tried to avoid having a slighlty different pdm installation on every machine by using pdm-packer. After some investigation I believe that pdm is not suitable to be packed as a zip app, due its usage of file at various places right now. @models.environment.py i believe there it is no problem. there are some more places where file is used, but I did stop investigating at this point. Question.: I am considering either going towards PDM as a zip app, pipx with requirements.txt, or PDM deployed with a windows installer... I did not make up my mind yet, but I definitely do not want to work against PDMs project goals. |
Not the case now, it won't work in a zipapp with the |
Closed by 2.3.3 |
Is your feature request related to a problem? Please describe.
Packaging 22.0 introduced a number of backwards incompatible changes, which can break projects using PDM:
In order to avoid problems with PDM updates breaking my CI pipelines, I have switched to installing PDM as
pip install pdm~=2.3.1
, in order to get bugfix releases but manually opt in to feature releases.However, PDM doesn't lock its own dependencies, so a major release of Packaging 22.0 introduced several incompatible changes, without any update to the PDM version.
Describe the solution you'd like
PDM should lock the exact versions of its own dependencies, so that installing the same version of PDM gives the same results each time. Major version updates of dependencies that affect the PDM interface in backwards-incompatible ways, such as
packaging
, should at least only be done on feature releases of PDM.The text was updated successfully, but these errors were encountered: