Live data from Hacker News

PyPI Blog: Project Quarantine

blog.pypi.org

41–50 of 62 posts

Re: PyPI Blog: Project Quarantine

#41
post #37

Earlier quoted context omitted.

The 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.

The PSF has a saying in which is the default installer and how pypi is run.

They 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.

Re: PyPI Blog: Project Quarantine

#42
post #37

Earlier quoted context omitted.

The PSF has a saying in which is the default installer and how pypi is run.

They 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.

They 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.

Re: PyPI Blog: Project Quarantine

#43
post #21

Earlier quoted context omitted.

They won't pay anything unless they are forced to do so. Basic capitalism brings to externalise costs to society

Perhaps, but can you explain how an alternative to capitalism wouldn’t result in people no paying for a service they don’t have to pay for?

In an alternative system you can get a salary from the government to work on open source software, and the companies pay for that in taxes. Of course you must embargo Malta, Netherlands and all the other countries that thrive on grabbing taxes from other countries.

Re: PyPI Blog: Project Quarantine

#44
post #42

Earlier quoted context omitted.

They 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.

They 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.

We'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.

Re: PyPI Blog: Project Quarantine

#45

Earlier quoted context omitted.

> Who is "they"? The PyPI and Pip developers of course.

Those are largely disjoint sets, and the post in question is about PyPI.

So? The issue requires coordination between Pip and PyPI. I don't see what point you're trying to make.

Re: PyPI Blog: Project Quarantine

#46
post #21

Earlier quoted context omitted.

They won't pay anything unless they are forced to do so. Basic capitalism brings to externalise costs to society

Perhaps, but can you explain how an alternative to capitalism wouldn’t result in people no paying for a service they don’t have to pay for?

People in more communally oriented societies pay for things they "don't have to" pay for because there's a social obligation.

Re: PyPI Blog: Project Quarantine

#47
post #24

> The one project cleared was a project containing obfuscated code, in violation of the PyPI Acceptable Use Policy. Interesting, I didn’t know that. While I haven’t released anything obfuscated on PyPI, I’ve certainly written Python projects that include obfuscated code by necessity, namely scrapers packing duktape (embedded JS interpreter) and third party obfuscated JS blobs to generate signatures and stuff. I know…

They also allow binary packages if you want an easy way of hiding malware.

Re: PyPI Blog: Project Quarantine

#48

Earlier quoted context omitted.

Those are largely disjoint sets, and the post in question is about PyPI.

So? The issue requires coordination between Pip and PyPI. I don't see what point you're trying to make.

The 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).

Re: PyPI Blog: Project Quarantine

#49

Earlier quoted context omitted.

So? The issue requires coordination between Pip and PyPI. I don't see what point you're trying to make.

The 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).

The simplest way to fix this problem is to support namespaces, which PyPI absolutely does need to be aware of.

Re: PyPI Blog: Project Quarantine

#50

Earlier quoted context omitted.

The 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).

The simplest way to fix this problem is to support namespaces, which PyPI absolutely does need to be aware of.

This 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/

Post reply on HN