[Distutils] Fw: Q about best practices now (or near future)

[Vinay Sajip]

Sorry, accidentally left distutils-sig off when replying.


----- Forwarded Message -----
> From: Vinay Sajip <vinay_sajip at yahoo.co.uk>
> To: Nick Coghlan <ncoghlan at gmail.com>
> Cc: 
> Sent: Thursday, 18 July 2013, 8:41
> Subject: Re: [Distutils] Q about best practices now (or near future)
> 
>>  From: Nick Coghlan <ncoghlan at 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
>