4 ms·

Python packaging scenarios by the creators of ruff

16 points by BiteCode_dev 2y ago

deckiedan 2y ago
This is interesting. But still pretty early, right? (As in, no real docs, not ready for publication...)? It looks like a start of a packages.lock.json kind of tool for dependency resolution eventually? Or am I missing something?
meitham 2y ago
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
- codexb 2y ago
  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.
  - charliermarsh 2y ago
    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. [1] https://github.com/astral-sh/uv https://github.com/astral-sh/uv [2] https://github.com/pypa/pip/pull/12580 https://github.com/pypa/pip/pull/12580
- aeurielesn 2y ago
  More than pip, the problem is setuptools. But alternatives are truly required because these two projects had become inflexible monolith.
zanie 2y ago
Hi! 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/pip_install_scenarios.rs https://github.com/astral-sh/uv/blob/main/crates/uv/tests/pi...
- odie5533 2y ago
  Might be good to include in the top of the README why the tool exists and possible use cases that people might use it for. It appears to be a way to check that a package being published has proper and expected dependency trees?

16 points by BiteCode_dev 2y ago

This is interesting. But still pretty early, right? (As in, no real docs, not ready for publication...)? It looks like a start of a packages.lock.json kind of tool for dependency resolution eventually? Or am I missing something?

meitham 2y ago

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

codexb 2y ago
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.
- charliermarsh 2y ago
  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. [1] https://github.com/astral-sh/uv https://github.com/astral-sh/uv [2] https://github.com/pypa/pip/pull/12580 https://github.com/pypa/pip/pull/12580
aeurielesn 2y ago
More than pip, the problem is setuptools. But alternatives are truly required because these two projects had become inflexible monolith.

zanie 2y ago

Hi! 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/pip_install_scenarios.rs https://github.com/astral-sh/uv/blob/main/crates/uv/tests/pi...

odie5533 2y ago
Might be good to include in the top of the README why the tool exists and possible use cases that people might use it for. It appears to be a way to check that a package being published has proper and expected dependency trees?