Totally, for that I tend to use a very precise matrix of pip-tools generated constraint files a.k.a. a “DIY lockfile”. Though, when generating those files, when I have a known list of incompatible versions, I also inject something like -c known-broken-constraints.in into the requirements input file so that they are taken into account when making the resulting constraint file. This allows me to (1) have direct dependencies stated clearly and (2) a distinct list of known issues with things that are transitive deps most of the time and (3) a constraint file with the entire deptree pinned transitively.
Just to be clear, I was referring to the current of the canonical spec and the tested the behavior in both relatively older and latest versions of pip to confirm they adhered to it. And looking back a decade to when the PEP was first provisionally accepted, I can confirm that the relevant portions of the PEP still read essentially the same as they do now, and it still included the same examples making explicitly clear that a version spec of == 1.1 will not match 1.1.post1.
Yup, correct, as mentioned above, aside from other theoretically possible rare corner cases.
1 Like