Possibility of changing content_hash in lock file

[jbrantly]

Somewhat similar to the original issue in #642, my team has found that resolving merge conflicts in the pdm.lock file seems unnecessarily difficult due to the top-level content_hash property changing whenever dependencies are added or removed. This forces the merger to arbitrarily pick one of the hashes and then run pdm install or pdm lock --refresh to calculate a new hash.

I'm wondering if having the list of dependencies included in this hash calculation is really necessary? I know this project was inspired by npm and, for example, the package-lock.json file does not have a top-level hash and avoids this issue.

My assumption is that npm/node supports multiple versions of transitive dependencies at once and Python does not, so PDM needs to go through the whole resolving algorithm to make sure all version constraints are still satisfied? If that's the case, I can understand the need, but figured I'd start a discussion to make sure.

[hmoffatt]

This is a a problem if you have several PRs that update pdm.lock eg branches that add or update packages, or use RenovateBot. After the first PR is applied, all of the others need to be refreshed.

It would be useful to be able to disable the content_hash unless there is an absolute requirement for it.