13 ms·

They need to store the version requirements metadata outside the packages. Having to download the entire wheel just to see whether it is compatible is ridiculou

by sjburt 6y ago

They need to store the version requirements metadata outside the packages. Having to download the entire wheel just to see whether it is compatible is ridiculous. This could all be computed by downloading an index file, then performing the resolution. They made a half-assed attempt when pypa/pip added the "data-requires-python" tag, but that covers python interpreter version only, it needed to have been done for all dependencies. What's especially irksome is that Debian and RPM both solved this 20+ years ago and python has refused to learn any lessons.

woodruffw 6y ago
This is the subject of discussion in this Warehouse (the PyPI backend) issue[1]. The TL;DR is that it probably requires a PEP. FD: I've been working on adjacent features in PyPI. [1]: https://github.com/pypa/warehouse/issues/8254 https://github.com/pypa/warehouse/issues/8254
deleted 6y ago
[deleted]
cozzyd 6y ago
yeah, why not just use libsolv or something?
jrochkind1 6y ago
rubygems went through several iterations of API to try to deal with this, including yes, starting with a dependency-info-only API. I wish different language/platform communities were better at learning from each other (and this does go in all directions). In the field of software these days, we don't do much learning from prior art. It's just too hard to keep up with it all. Heck, I recall this happening with rubygems -- the introductio of the dependencies API to efficiently get the minimum data needing for resolving dependencies before downloading actual packages, and then several iterations on it -- and I can't find any actual documentary evidence of it to share right now. I don't know how anyone WOULD use it as prior art; the source code for a fairly complex project in a language you aren't familiar with isn't going to work, even if you knew to go look for it, which why would you.
danmur 6y ago
Same reason poetry has slow (but accurate) dependency resolution. It would be nice to have as part of the repo API.
orf 6y ago
Pypi does have a json API that returns package dependencies, if the uploaded file is compatible. See the “requires’ key here: https://pypi.org/pypi/Django/json https://pypi.org/pypi/Django/json

by sjburt 6y ago

woodruffw 6y ago

This is the subject of discussion in this Warehouse (the PyPI backend) issue[1]. The TL;DR is that it probably requires a PEP. FD: I've been working on adjacent features in PyPI. [1]: https://github.com/pypa/warehouse/issues/8254 https://github.com/pypa/warehouse/issues/8254

deleted 6y ago

[deleted]

cozzyd 6y ago

yeah, why not just use libsolv or something?

jrochkind1 6y ago

rubygems went through several iterations of API to try to deal with this, including yes, starting with a dependency-info-only API. I wish different language/platform communities were better at learning from each other (and this does go in all directions). In the field of software these days, we don't do much learning from prior art. It's just too hard to keep up with it all. Heck, I recall this happening with rubygems -- the introductio of the dependencies API to efficiently get the minimum data needing for resolving dependencies before downloading actual packages, and then several iterations on it -- and I can't find any actual documentary evidence of it to share right now. I don't know how anyone WOULD use it as prior art; the source code for a fairly complex project in a language you aren't familiar with isn't going to work, even if you knew to go look for it, which why would you.

danmur 6y ago

Same reason poetry has slow (but accurate) dependency resolution. It would be nice to have as part of the repo API.

orf 6y ago

Pypi does have a json API that returns package dependencies, if the uploaded file is compatible. See the “requires’ key here: https://pypi.org/pypi/Django/json https://pypi.org/pypi/Django/json