On 15 October 2014 12:20, Stefan Krah <stefank...@freenet.de> wrote: > > > At this point (and possibly before) you are just trolling and not worth > any further correspondence. If some of your feigned surprise questions > are actually genuine, I recommend walking away from the keyboard for a > couple of weeks and reading some literature. > > Otherwise it is just a waste of time to attempt any further conversation.
Stefan, I personally apologise if at any point you, or any other developer that chooses to use non-PyPI hosting, has ever been (or even felt) personally attacked over your hosting choices. There's no way we can hope to ensure that folks that are passionate about the end user experience offered by the Python packaging ecosystem first come up to speed on the subtleties of copyright licensing (and the concerns around the current clause in PyPI's conditions of use that ensures, amongst other things, the legal right to operate PyPI mirrors) or US export restrictions (and the fact that uploading to PyPI requires agreeing to abide by them, which may not be an acceptable condition for non-US based developers). However, balancing multiple competing viewpoints is *why* we have the Python Enhancement Proposal process, and this is why the accepted PEPs have always included external hosting support, even when the feature has been missing from some of the earlier draft proposals. You don't need to fight that battle any more - it was won a long time ago (and was never really in danger of being lost). At the same time, silently introducing additional points of failure into users' infrastructure, and especially introducing silent vulnerabilities to man-in-the-middle DNS hijacking attacks, is *not* OK. Eliminating those two problems has been the focus of many of the more controversial PyPI changes over the past year or more, so it is entirely understandable that developers that choose to use external hosting *have* felt personally attacked, especially when other developers have failed to understand why "just host your packages on PyPI" isn't always going to be an acceptable answer. The latest proposal in PEP 470 is designed to provide a mechanism which is completely explicit (so end users always know when they're depending on additional repositories beyond PyPI), while also relatively streamlined (so end users don't complain when a developer chooses to make use of the external hosting support). The previous design in PEP 438 ended up failing on both of those counts, which is why there is now this new proposal to replace it with a different mechanism that has been designed to address the existing usability challenges. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
