I wrote this library / tool. Basically we needed a way to test arbitrary packaging situations and, instead of manually constructing packages or finding representative situations on PyPI, we wrote a tool that could construct them automatically and host the required dependency trees.
We use these scenarios in uv's test suite[1] (our package manager).
There was an initial attempt to use these scenarios for testing in pip itself, but we'd need to invest a bit more into the tool for it to be feasible since resolver behavior can be different but still "correct" based on implementation details.
I think competition is good but I fail to see the problem with pip that these alternatives are trying to address! Since pyproject.toml became fully supported in pip it just strikes me as better than all the other alternatives including poetry etc
I'm not sure what issue this is trying to solve either. It looks like it could be used to vendor dependencies but also publish them to an index? I don't understand the purpose of including a hash in the package name.
This project is specifically about publishing test cases for package managers -- it's not a package manager or a registry itself. We use it in uv [1] to test that our resolver is spec compliant. pip also explored using it for the same reason.
I wrote this library / tool. Basically we needed a way to test arbitrary packaging situations and, instead of manually constructing packages or finding representative situations on PyPI, we wrote a tool that could construct them automatically and host the required dependency trees.
We use these scenarios in uv's test suite[1] (our package manager).
There was an initial attempt to use these scenarios for testing in pip itself, but we'd need to invest a bit more into the tool for it to be feasible since resolver behavior can be different but still "correct" based on implementation details.
[1]: https://github.com/astral-sh/uv/blob/main/crates/uv/tests/pi...