Sorry, accidentally left distutils-sig off when replying.
----- Forwarded Message ----- > From: Vinay Sajip <vinay_sa...@yahoo.co.uk> > To: Nick Coghlan <ncogh...@gmail.com> > Cc: > Sent: Thursday, 18 July 2013, 8:41 > Subject: Re: [Distutils] Q about best practices now (or near future) > >> From: Nick Coghlan <ncogh...@gmail.com> > > > >> Then (help) write the missing PEP! PEP's don't appear out of > nowhere, > > I think I have been helping as and when I can by participating in the various > discussions, but the PEP has to be written by a champion. I clearly can't be > a champion for this, else why would I be working on distlib? That's what I > currently see as the way forward, obviously, but it's premature to look at a > PEP for it because it hasn't had enough exposure or peer review. > > I have no particular axe to grind against pip - I did a lot of the core work > for > the single code-base port, speeded up the test suite a fair bit, and have > contributed other bits and bobs. However, it is the past and present of > packaging, as I see it, and not a worthy long-term future - it has too much > technical debt. As the de facto installer for Python, pip needs no additional > new endorsement, in my view. If I had to choose, I would say I find none of > the > choices especially appetising, but I would choose an explicit bootstrap over > the > others. Note that installing Distribute/pip was explicitly removed from the > pyvenv script before 3.3 beta, because of python-dev concerns about promoting > specific third-party solutions in the stdlib (even though they were the > defacto > tools for Python 3.x, and endorsed as such by python-dev).. > > Nothing has essentially changed from the 3.3 beta time frame. People still > use > pip, just as they always did. The recommendation from python-dev is as it > always > was (use pip), with a slight alteration on the Distribute front due to the > merge > with setuptools. Neither pip nor setuptools are *significantly* better than > they > were in functional terms, and if they weren't the right solution when > distutils2/packaging was mooted, I don't see why that should have changed > now. > >> these approaches (up to and including misstating that dislike as "not > >> going to happen"), that just means the arguments in favour would need >> to be a bit more persuasive to convince me I am wrong. > > That's not how "not going to happen" comes across. You're > saying it's a misstatement in this off-list mail, but as you are the > packaging BDFL, some people on-list would just give up when they saw that. > >> The problem statement also needs to be updated to cover the use case >> of an instructor running a class and wanting to offer a local PyPI >> server (or other cache) without a reliable network connection to the >> outside world, since *that* is the main argument against the >> bootstrapping based solutions. > > > How widespread is that scenario, really, in this day and age? I consider this > a > straw man. If that really is a case to cover, you can make a getpip script > cover > this contingency with a command-line argument, the pip and setuptools > packages > can be stored on the local PyPI cache, and so on. It's no more onerous than > explaining to the students, for example, the pip command line parameters you > would need to specify to access a local PyPI cache. From my experience, over > the > course of a class students will run many commands, some of which they don't > fully understand, under the guidance of the instructor. > > I have to say, I'm not comfortable with the *level* of some of the > arguments/points put forward - for example, that "we already had a get-pip > command, using curl URL | python". They come across as unconsidered, more > like rationalisations for a course already set, and it's hard to engage in a > debate which doesn't feel right. > > Regards, > > Vinay Sajip > _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
