Why default save strategy is minimum instead of compatible?

[g0di]

Hello,

The title is pretty self explanatory. Node.js Yarn/Npm use a compatible save strategy for example. I was wondering about the reasons for using minimum as the default and the pros/cons compared to the compatible strategy. Is there is different cases in which one should be preferred over the other?

Thanks ;)

[pawamoy]

For this reason: https://iscinumpy.dev/post/bound-version-constraints/.

Upper bounds do more harm than good within the Python ecosystem. Only use them when you know the upper version does not work with your project.

Python uses flat dependencies, meaning only one version of each dependency can be installed in a given environment, meaning dependencies resolution is harder, and the more constraints there are within the dependencies, the harder it is to resolve. Constraints contaminate dependents.

In other ecosystems, where dependencies can be installed in a nested manner, this is less problematic.

[g0di]

Thanks for the quick answer and the super interesting read. I did not have time to go through now but I'll definitively go over it. This is pretty clear to me now why we should avoid using the compatible strategy.

However, in the case of an application (so not a Python library that will be distributed), could it make sense to switch for compatible instead?

[pawamoy]

You're welcome!

[g0di]

FYI, I've tried to use the exact strategy for a test application. It works well but my issue is that it makes really hard to actually update the dependencies. For example I'm adding pdm add fastapi. It saves the exact latest version of it in pyproject.toml. Now imagine, later on, I want to update fastapi to a newer version that just came out. The only ways to do it is to either manually update the pyproject.toml file with exact new version and sync OR, remove fastapi then re-add it.

This is because the pdm update command actually update only the lockfile, not the pyproject.toml. Moreover, reusing pdm add fastapi is never overriding the pyproject.toml as long as fastapi is already mentionned in dependencies

I'm unsure if those are the ways of doing it. I'm wondering if at some point PDM documentation should not provide some guidelines/best practices when managing a Python application compared to a library.

In the end, I found that using wildcard strategy would be easier for application. This way, you can easily update/downgrade your depndencies using pdm update command. You then just rely on the lockfile for dependencies versions. The only downside IMO is that it makes it harder to actually understand the versions used by the application because the lockfile is actually harder to read compared to a simple requirements.txt file

[pawamoy]

Have you tried pdm update fastapi --unconstrained?

[g0di]

I feel really retarded because I was almost sure I gave it a try and it did not work. I retried after your message and, indeed, it successfully updated both lockfile and pyproject.toml...

Thanks again ...

Note: I still think it could be interesting to have some guidelines regarding managing Python applications through PDM compared to a library

[pawamoy]

Hahaha no worries, PDM has a lot of features and options, and the whole subject is a rabbit hole, it takes some trial and error :)