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

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 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.