Re: [Python-Dev] Yearly PyPI breakage
Nick Coghlan <ncoghlan <at> gmail.com> writes:
I know you're not happy with myself and the other distutils-sig folks regarding the decision to deprecate and remove automatic link spidering,
More accurately: Not happy with the removal of the checksummed "explicit" mode. What I would have preferred is a FreeBSD-like ports system. FreeBSD has been used in huge and secure installations, so the I don't buy the reliability and security arguments that are used in favor of centralization. But centralization seems to be a goal in and of itself these days (and that isn't limited to Python).
nor with the PSF regarding the current Terms of Service around uploads to PyPI, but that doesn't make it OK to start off-topic threads on python-dev just because you're a CPython core developer in addition to being a PyPI user.
Alexander thought otherwise: https://mail.python.org/pipermail/python-dev/2015-October/141840.html "Given that ensurepip is part of stdlib, I am not sure this is an accurate statement. Even if it was, did you make any effort to discuss the proposal outside of a small group subscribed to distutils ML?" I completely agree with that. Fredrik Lundh is also affected (and might not have received any mail, same as me): https://pypi.python.org/pypi/PIL
It *definitely* doesn't make it OK to accuse people of conspiring against you when they answer your question in good faith, just because their answer is the official distutils-sig/PyPA one (which was approved through the PEP process in PEP 470).
I'm not sure what you are referring to. Donald posted a link to PEP 470, in my response to Nathaniel I acknowledged this. In my exchange with Łukasz we both came to the conclusion (I think) that further discussion would be futile. IMO all responses from Brett, Donald, Nathaniel and Łukasz were reasonable and I haven't accused them of conspiring in the slightest. I see that the PEP was accepted by Paul Moore. I couldn't even dream of accusing Paul Moore of any kind of conspiracy. He's one of the most reasonable (and *genuinely* polite) people on these mailing lists. Or are you referring to a super-condescending flame bait where someone cloned a private website, assumed general ignorance and then proceeded to offer a hostile fork to anyone who would be interested? Well, I accepted the flame bait.
- writing to psf-legal to let them know whether or not Van Lindberg's draft updates to the Terms of Service would be sufficient to make you comfortable with uploading cdecimal to PyPI in addition to bundling it with the standard library under your existing Contributor Licensing Agreement: https://bitbucket.org/vanl/pypi/src/default/templates
Okay, so there was recent progress here. This is actual news to me. Do you remember what kind of derision I went through for just suggesting something like that a couple of years ago? Yes, you supported me, but what about the others? Or that Van Lindberg was in the merry group of Twitter heroes who were gloating about the fact that (in their opinion) I could not do anything about the first hostile fork? Technically, he didn't gloat, but suddenly legal advice was apparently readily available. https://pypi.python.org/pypi/m3-cdecimal I can assure you that CoCs or "diversity statements" won't help you at all. Stefan Krah
On 05/05/2016 23:22, Stefan Krah wrote
Fredrik Lundh is also affected (and might not have received any mail, same as me):
He might be, but clearly the Python community as a whole is not impacted. From what I see the latest version of PIL that is available is 1.1.6, which requires Python 1.5.2 or higher, and has the following stats:- 0 downloads in the last day 0 downloads in the last week 0 downloads in the last month I wish I could vent my feelings regarding your comments earlier in this thread but I won't, as apparently core developers can say what they like with no comeback, whereas plebs like me can and will get hammered by the Python community, despite having explained that a combination of anxiety, depression, chronic fatigue syndrome, insomnia, autism and diplopia makes life rather difficult. Unless of course you have similar problems, in which case please say so. The rest of the community might not understand, I certainly will. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
Fredrik Lundh is also affected (and might not have received any mail,
same as me):
He might be, but clearly the Python community as a whole is not impacted. From what I see the latest version of PIL that is available is 1.1.6, which requires Python 1.5.2 or higher,
Indeed -- Fredrik never made any effort to support pypi, pip, etc. -- that's why the Pillow fork was started in the first place. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On May 05, 2016, at 11:58 PM, Mark Lawrence via Python-Dev wrote:
On 05/05/2016 23:22, Stefan Krah wrote
Fredrik Lundh is also affected (and might not have received any mail, same as me):
Maybe, but then there's the friendly fork: https://pypi.python.org/pypi/Pillow/3.2.0 -Barry
On 06/05/2016 00:06, Barry Warsaw wrote:
On May 05, 2016, at 11:58 PM, Mark Lawrence via Python-Dev wrote:
On 05/05/2016 23:22, Stefan Krah wrote
Fredrik Lundh is also affected (and might not have received any mail, same as me):
Maybe, but then there's the friendly fork:
https://pypi.python.org/pypi/Pillow/3.2.0
-Barry
Where is the relevance to my words that you've snipped? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On Thu, 5 May 2016 at 16:00 Mark Lawrence via Python-Dev < python-dev@python.org> wrote:
On 05/05/2016 23:22, Stefan Krah wrote
Fredrik Lundh is also affected (and might not have received any mail, same as me):
He might be, but clearly the Python community as a whole is not impacted. From what I see the latest version of PIL that is available is 1.1.6, which requires Python 1.5.2 or higher, and has the following stats:-
0 downloads in the last day 0 downloads in the last week 0 downloads in the last month
I wish I could vent my feelings regarding your comments earlier in this thread but I won't, as apparently core developers can say what they like with no comeback,
I don't think that's fair. Several people pointed out that Stefan's initial email was off-topic and somewhat rude, but was probably given some slack due to the fact that having deployments to the Cheeseshop fail can be frustrating (leeway I think anyone posting here would have received). At this point I think there's nothing new to be said and unless someone wants to take a more drastic step like a formal CoC complaint or calling for the heads of the management of distutils-sig on spikes, this thread has run its course.
On May 5, 2016, at 6:22 PM, Stefan Krah <stefan@bytereef.org> wrote:
Nick Coghlan <ncoghlan <at> gmail.com> writes:
I know you're not happy with myself and the other distutils-sig folks regarding the decision to deprecate and remove automatic link spidering,
More accurately: Not happy with the removal of the checksummed "explicit" mode. What I would have preferred is a FreeBSD-like ports system. FreeBSD has been used in huge and secure installations, so the I don't buy the reliability and security arguments that are used in favor of centralization. But centralization seems to be a goal in and of itself these days (and that isn't limited to Python).
Let me say outright that there is nothing wrong with a well designed, ports like system. However, PyPI was not that and the vast bulk of packages were not using it in that fashion. At the time of PEP 470 being written a mere 59 out of 65,232 (at the time) projects were utilizing the feature that allowed people to safely do a ports like system. That's roughly 0.09% of all of the projects on PyPI which meant those projects were in a very serious minority. Thus it is only natural that the expectations end users had when installing software was that it was coming from PyPI, not from some external host and they made decisions based around those expectations and when those expectations were violated they came to the people operating PyPI and developing pip and were at best very confused, and at worst irate at *us*. It's also true that there are benefits and cons to both a repository centric approach and a ports style approach, however since we were attempting to do both in one repository it typically meant that we got all of the cons of both systems, but we couldn't ever take advantage of any of the unique benefits of either system since it would only apply to some fraction of the projects. This meant that improvements that would help people installing 99.11% of projects would end up getting blocked by 0.09% of projects. At the end of the day, attempting to both things in one repository just wasn't working out very well in the general case, so we needed (IMO) to pick one way and stop supporting the other way. I personally think it's a pretty obvious choice to go the way that we did, given that the overwhelming majority of projects were already being used that way. That being said, I don't think the characterization of "centralizing" is really accurate here. People are still free to host their projects wherever they want and pip (and easy_install) can be used to install them. All it requires is telling pip where it needs to look in addition to the default location (PyPI), which can be configured via the CLI, environment variables, or a number of configuration files at the system, user, and virtual environment level. You're free to continue providing a page on PyPI to enable discovery of your project and you can include in that page instructions on how to install your project.
nor with the PSF regarding the current Terms of Service around uploads to PyPI, but that doesn't make it OK to start off-topic threads on python-dev just because you're a CPython core developer in addition to being a PyPI user.
Alexander thought otherwise:
https://mail.python.org/pipermail/python-dev/2015-October/141840.html
"Given that ensurepip is part of stdlib, I am not sure this is an accurate statement. Even if it was, did you make any effort to discuss the proposal outside of a small group subscribed to distutils ML?"
I completely agree with that.
We've sort of hijacked the PEP process to do something that it wasn't really meant to do. Changes like PEP 470 have nothing to do with what Python itself does and thus it's really outside of the realm of where python-dev really needs a say or notification. In Alexander's example of PEP 495 it was talking about adding a new API to Python itself, thus it makes sense that python-dev should be told about that PEP, and in cases where we needed to change the standard library we've done that discussion on python-dev (such as with PEP 453). The python-dev list is not the list to notify people of changes to things in all corners of the Python ecosystem. If people want to get involved or keep abreast of the changes in the external projects of PyPI, pip, setuptools, etc then they should subscribe to the places that those changes get discussed-- which is distutils-sig. Packaging already has enough problems with getting bogged down in "why wasn't I consulted" and bikeshedding, I don't think that inviting folks (and nothing against python-dev here) a chance to try and re-legislate an agreed upon change after the fact is going to provide much in the way of benefits and will instead just contribute further to stymying efforts to move packaging forward. If it was decided that we really need all PEPs announced on python-dev and python-dev given a chance to weigh in, I would advocate for packaging to stop using the PEP process all together and create our own process to mirror the PEP process because again, we're not using the PEP process because these things naturally fall under what the PEP process was designed to cover, we're using it because it was there already and close enough that we could hijack it and it was moderately easier to just do that. If the downsides of using the PEP process become greater than the effort to come up with our own process then I think it's a no brainer to just do our own thing.
Fredrik Lundh is also affected (and might not have received any mail, same as me):
I've personally emailed the PIL offer several times through various email addresses over several years and have never gotten a response. At this point I can only assume either they are willfully ignoring those messages or they've completely changed their contact information in a way that I have not been able to find updated contacted information for at all.
Technically, he didn't gloat, but suddenly legal advice was apparently readily available.
I'm not going to respond to the rest of this, because I don't think it's possible for you and me to have a constructive discussion on these other issues. However, I do want to point out that the PSF is the legal entity behind PyPI itself and Van is both a board member and a lawyer. I don't recall what exactly was discussed with who about m3-cdecimal, but it's completely reasonable that when a legal question comes up with PyPI that we consult the PSF board members, particularly the ones who are lawyers. I do recall that the last time m3-cdecimal came up [1] you (again) brought up issues you had with PyPI in an inappropriate venue and as far as I know, you never actually used any of the contact channels that you were offered to try and resolve the issue that you had with a project on PyPI. [1] https://bugs.python.org/issue22483 ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Donald Stufft <donald <at> stufft.io> writes:
Technically, he didn't gloat, but suddenly legal advice was apparently readily available.
I'm not going to respond to the rest of this, because I don't think it's possible for you and me to have a constructive discussion on these other issues. However, I do want to point out that the PSF is the legal entity behind PyPI itself and Van is both a board member and a lawyer. I don't recall what exactly was discussed with who about m3-cdecimal, but it's completely reasonable that when a legal question comes up with PyPI that we consult the PSF board members, particularly the ones who are lawyers.
It is not reasonable at all. A normal human being would try to consider first if an author has moral rights as opposed to legal rights and maybe pick up the phone or use private email instead of escalating everything to Twitter. Also, what was discussed was not whether the PSF had any right to remove m3-cdecimal but rather whether *I* had any rights to *demand* the removal. People concluded gleefully that I hadn't any (I still think they're mistaken and an enterprising Oracle lawyer could come to a different conclusion, but that's besides the point). Stefan Krah
participants (6)
-
Barry Warsaw -
Brett Cannon -
Chris Barker -
Donald Stufft -
Mark Lawrence -
Stefan Krah