5 ms·
Who is "they"? PyPI is an index; it doesn't control your installing client. (This is a larger issue - or feature, depending on your perspective - with Python p
by woodruffw 2y ago
Who is "they"? PyPI is an index; it doesn't control your installing client.
(This is a larger issue - or feature, depending on your perspective - with Python packaging. But it's important to understand that PyPI itself can't force `pip` or any other client to pick any particular resolution order between indices.)
- LtWorf 2y agoFor all intents and purposes "pip" is the official client. It is referenced in the official documentation https://docs.python.org/3/installing/index.html https://docs.python.org/3/installing/index.html
- woodruffw 2y agoThe fact that pip is the official client isn’t in dispute. The point was that pip and PyPI are different entities, per a larger pattern of devolved ownership/control/standards-over-tools in Python packaging. PyPI has little to no say over how pip and other tools choose to handle resolutions across multiple indices.
- LtWorf 2y agoThe PSF has a saying in which is the default installer and how pypi is run.
- pyuser583 2y agoPSF has little control over anything. The Python ecosystem is consensus-based.
- woodruffw 2y agoThey have a say insofar as they can participate in the same standards process as everyone else. But no, the PSF has no unique say in how PyPI is run, or how pip behaves. This is a pretty fundamental aspect of how Python-qua-ecosystem works.
- LtWorf 2y agoThey have a say in that if it doesn't behave like they want they can point the documentation to something that does. If pip is the tool linked in the documentation it's the official one that has the PSF's blessing, clearly.
- woodruffw 2y agoWe're going in circles. PSF can't unilaterally change any documentation of particular relevance here; the most immediately relevant docs would be controlled by PyPA and PyPI itself. The former has a standards/community review process, and the latter is particular to PyPI. But again: this has nothing to do with blessings or not. The fact that pip is the official installer and PyPI is the official index does not mean that everything about them stems from an official edict. That's not how Python's community is structured, and it's certainly not how the technical development on anything in Python packaging has ever progressed.
- LtWorf 2y agoWho controls the python.org domain that I linked? Am I wrong to think that PSF controls it?
- woodruffw 2y agoPSF controls that domain. But that domain doesn’t host PyPI (anymore) or the PyPA docs, so I’m not sure what connection you’re making there.
- LtWorf 2y agohttps://docs.python.org/3/installing/index.html https://docs.python.org/3/installing/index.html so it's PSF's decision to document using pip, right? And they might decide to change that page without asking for anyone's consent right? So they also don't get to complain about pip's shortcomings because it is their decision to point users towards pip. Correct? Have I been explicit enough for you now?
- IshKebab 2y ago> Who is "they"? The PyPI and Pip developers of course.
- woodruffw 2y agoThose are largely disjoint sets, and the post in question is about PyPI.
- IshKebab 2y agoSo? The issue requires coordination between Pip and PyPI. I don't see what point you're trying to make.
- woodruffw 2y agoThe issue does not require coordination; that's the point. It's a behavioral aspect of `pip` that's completely opaque to PyPI, because all PyPI does is serve index responses to installers. It doesn't know how many indices the installer contacts, or the order in which it contacts them (and it has no good reason to know those things, ever).
- IshKebab 2y agoThe simplest way to fix this problem is to support namespaces, which PyPI absolutely does need to be aware of.
- woodruffw 2y agoThis would not be meaningfully addressed by namespaces, since there's no authoritative, authenticated unique name system across indices. Two separate indices can (and will, based on what ecosystems like piwheels do[1]) advertise `foo/*`-namespaced packages, leaving installers where they are today. (I think namespacing is a good idea regardless, if only because it eliminates artificial scarcity in a one-level namespace.) [1]: https://www.piwheels.org/ https://www.piwheels.org/