3 ms·

All major repositories editorialize to some extent, they would be awful if they did not. For instance, PyPI will take down your software if we determine it to

All major repositories editorialize to some extent, they would be awful if they did not. For instance, PyPI will take down your software if we determine it to be malicious in some way, which is extending editorial control over what's on PyPI. Generally speaking, though, PyPI does not concern itself with the contents of the packages shipped through it as long as they are reasonable packages. If a project wants to break compatibility, then that's on them. We strive to let projects manage themselves, in whatever way they think makes the most sense.

sam0x17 4y ago
> For instance, PyPI will take down your software if we determine it to be malicious in some way, which is extending editorial control over what's on PyPI. Where this breaks down and gets tricky I feel, though, is when you get into examples where the package maintainer makes the newest version essentially useless (but in an otherwise harmless way) in protest of some grievance. I think this is a perfectly legitimate action for a maintainer to take as long as they aren't literally installing malware or opening up security vulnerabilities. Package systems stepping in in these scenarios and "bailing out" all the companies that rely on the package by taking it over are effectively silencing the maintainer. My smell test for this is if the ISP or hosting provider wouldn't yank it, neither should the package system. Hosting providers will take down malware and illegal content, but they aren't going to do more than that, and that's how it should be imo in package systems. I think the benefit of developers' voices not being silenced vastly outweighs the humorous scrambling of a bunch of companies who failed to lock their version numbers for a few short hours. The same scramble happens all the time with real-world breaking changes anyway. If the maintainer wants to effectively yank their project, they should be allowed to do so. Otherwise you never really know if you are getting the maintainer's code, or whatever the package system decides should be the maintainer's code, which breaks the trust contract upon which package systems are built. This is another reason it's great that a lot of languages, like Crystal for example, have adopted a decentralized model.
- donaldstufft 4y ago
  PyPI doesn't currently prevent deletions at all, so a maintainer can just flat out delete their stuff if they want. Though we are discussing if we want to tighten that up at all. I would say that in the > 10 years of time I've been an admin on PyPI and even longer that I've been involved in Python's Packaging, I've never once seen anyone, but individuals placed front and center in who we're attempting to serve first and foremost. Businesses and other large orgs do come up from time to time, and we've generally been pretty good at making decisions that allowed those businesses to solve their problems on their own, without requiring the rest of the ecosystem to do it for them. In other words, our features we add for businesses tend to be unblocking them from being able to implement something they want, rather than taking on the responsibility of whatever thing they want.

sam0x17 4y ago

> For instance, PyPI will take down your software if we determine it to be malicious in some way, which is extending editorial control over what's on PyPI. Where this breaks down and gets tricky I feel, though, is when you get into examples where the package maintainer makes the newest version essentially useless (but in an otherwise harmless way) in protest of some grievance. I think this is a perfectly legitimate action for a maintainer to take as long as they aren't literally installing malware or opening up security vulnerabilities. Package systems stepping in in these scenarios and "bailing out" all the companies that rely on the package by taking it over are effectively silencing the maintainer. My smell test for this is if the ISP or hosting provider wouldn't yank it, neither should the package system. Hosting providers will take down malware and illegal content, but they aren't going to do more than that, and that's how it should be imo in package systems. I think the benefit of developers' voices not being silenced vastly outweighs the humorous scrambling of a bunch of companies who failed to lock their version numbers for a few short hours. The same scramble happens all the time with real-world breaking changes anyway. If the maintainer wants to effectively yank their project, they should be allowed to do so. Otherwise you never really know if you are getting the maintainer's code, or whatever the package system decides should be the maintainer's code, which breaks the trust contract upon which package systems are built. This is another reason it's great that a lot of languages, like Crystal for example, have adopted a decentralized model.

donaldstufft 4y ago
PyPI doesn't currently prevent deletions at all, so a maintainer can just flat out delete their stuff if they want. Though we are discussing if we want to tighten that up at all. I would say that in the > 10 years of time I've been an admin on PyPI and even longer that I've been involved in Python's Packaging, I've never once seen anyone, but individuals placed front and center in who we're attempting to serve first and foremost. Businesses and other large orgs do come up from time to time, and we've generally been pretty good at making decisions that allowed those businesses to solve their problems on their own, without requiring the rest of the ecosystem to do it for them. In other words, our features we add for businesses tend to be unblocking them from being able to implement something they want, rather than taking on the responsibility of whatever thing they want.