On 09.05.2014 13:44, Donald Stufft wrote: > > On May 9, 2014, at 4:12 AM, M.-A. Lemburg <m...@egenix.com> wrote: >> Donald: I don't think anyone is arguing that hosting packages on >> PyPI is a bad thing and PyPI as a service has gotten a lot better >> than it was a few years ago. > > Didn’t mean to imply that I thought it was otherwise. > >> >> However, I find it troubling that we as Python developers are *forcing* >> the whole Python world to put their code into PyPI. > > Forcing is a strong word. As of right now we’re "forcing" you to put it onto > PyPI if you want to install it without *any* flags to pip.
Which is what most people expect to be able to do. > You're more then > capable of hosting it externally if you wish, and pip will even tell the > people > who try to install it what they need to enable in order to install it. It even > allows people to say "I don't care about any of this crap, just make all the > external stuff work". > > Even if pip removed the external link handling all together and required you > to do something like: > > $ pip install --extra-index-url https://example.com/our-packages/ foo > $ pip install --find-links https://example.com/our-packages/ foo > > We still wouldn't be forcing anyone to upload things to PyPI. We are, however, > discouraging people from not hosting on PyPI and providing incentives to doing > that. This is all true, but in reality, you are making externally hosted packages second class citizens in Python land by requiring extra options even for package listings that are perfectly safe to download from other servers. As mentioned before: I can understand that you want to make downloads safe for users, but if a package is hosted on some other reliable servers and pip can check that it's a valid package, there's little to argue for not allowing such downloads. >> There are plenty good reasons not to do this, and sometimes it's >> even impossible if you want to stay legal (see the PEP for details). > > I re-read the reasons, I'm not sure I really agree with most (or all?) of them > however if people really want to do it, then there is nothing stopping them. > It's their choice and people on the *other* side of that who are installing > these packages also get to make a choice if they want to allow it or not. You don't have to agree with those reasons. Fact is, they exist, prevent package authors from uploading to PyPI and we as Python developers should respect those reasons. With the new infrastructure, it's far more attractive to host packages on PyPI than it was before, so people who do not host on PyPI will have carefully thought about this. >> Accordingly, we should respect those reasons make it possible for >> Python packages to live elsewhere, without having our tools put >> those packages into a bad light or making it harder for Python >> users to install such packages than needed. > > I'm not sure what "put it into a bad light" is supposed to mean here. Is it > about the warning? I've already removed that completely. It's using the same unfortunate strategy that setuptools used by requiring an option called --single-version-externally-managed to be able to install a package without all the .pth and egg logic (an option that pip now uses per default, BTW ;-)). I snipped the rest of the discussion and reliability, using unmaintained packages and projects using their own mirrors (which should really be the standard, not an exceptional case), because it's not really leading anywhere: At the time we discussed the PEP, security was the main concern, not reliability. Now that there is a secure way to reference external distribution files, I think we should revisit the defaults decision in the light of the new possibilities. BTW: The PEP mentions re-hosting tools to upload their packages to PyPI and also says "This re-hosting tool MUST be available before automated hosting-mode changes are announced to package maintainers." I am not aware of such tools. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 09 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
