Best practice for patching poetry.lock changes in package managers

[tjni]

Hi everyone (but in particular, to the poetry team):

In nixpkgs, we package (nearly always) only the most recent version of a Python package. In order to build a globally consistent package set using this strategy, we also ask or help packages migrate their dependencies to the latest versions. Because we cannot guarantee those packages release immediately, we have a mechanism through which we can fetch individual patches under the theory that individual commits can often be audited prior to a formal release.

I'd like some advice on how to handle this effectively, given that #496 is open. To illustrate an example of the problem that prompted me to post this:

1. In nixpkgs, we updated cleo to 2.0.1 to address CVE-2022-42966: exponential ReDoS cleo#284.
2. This breaks poetry, but conveniently there is Cleo 2.0 #7070 I can pull in.
3. There is no way to patch this because the metadata hash for poetry.lock has changed.
4. I went through all of the changes that updated poetry.lock since v1.2.2, audited them, and applied those patches.
5. This still doesn't merge. I think it is because one last change is done to the poetry.lock file only on the release branch.
6. It then occurred to me that, even if I audit this change and fix it up, I can't be sure that in the meantime I didn't miss other changes that were on master in between v1.2.0 and v1.2.2 that could not be picked up yet for various reasons (e.g. semantic versioning).

In this case, I can likely wait for v1.3.0 that looks likely to happen soon, but I'd like also to start this discussion about strategies for patching packages that use poetry without requiring the package owner to initiate a release.