pdm: groups at the top of pdm.lock don't update once lockfile exists

[abathur]

I'm not sure if this is expected behavior, a pdm problem, a sign we're holding pdm wrong, or a sign I'm holding dream2nix wrong--but I noticed that new/removed/renamed groups added to my pyproject.toml under [tool.pdm.dev-dependencies] don't get updated in the [metadata] section at the top of pdm.lock unless I remove the file before running nix run .#blah.lock.

[phaer]

@abathur Thanks for the report, that's not expected behavior! Going to have a look, a reproducer would be appreciated due to time constraints :)

[purepani]

I believe this happens because there's no actual lock invalidation. The lock module stores the hash in its own generated lock.json, but we generate the lock file using pdm, so the lock module has nowhere to actually put the hash.

I started implementing an invalidation scheme based on the content hash that pdm stores in the lock file, but it might be a little maintainer-heavy to do that since any change in how pdm generates the hash has to be implemented here as well(it's not that hard; there's a lockfile version indicator in the lock file, but it is a bit annoying). @phaer is there a better solution here? Only other one I can think of is just generating a second lock file for d2n.

[phaer]

@phaer is there a better solution here? Only other one I can think of is just generating a second lock file for d2n.

Thanks for reminding me of this. Not using the PDM module myself atm, so maybe @DavHau would have a better idea? To me your proposal sounds fine if we want to avoid storing our own invalidationHashes outside of pdm.lock, as we do with pip and nodejs.