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

[Nick Coghlan]

On 18 July 2013 17:44, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> Sorry, accidentally left distutils-sig off when replying.

Since I already replied off list, there's no way this dual
conversation over the same emails will get confusing, nope, uh-uh :)

> ----- 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,

I apologise for that crack - you deserve better than that.

> but the PEP has to be written by a champion. I clearly can't be
>> a champion for this,

As I said off-list, I think you might make a good champion for an
explicit bootstrapping PEP. I've already stated I'm no longer a fan of
implicit bootstrapping at first use, but some valid concerns have been
raised about the bundling approach as well. A middle ground where:

1. We provide an explicit bootstrapping script as a "getpip" module
2. This is added to the standard library in 3.4+
3. This is added to the Python Launcher for Windows for earlier versions
4. The following installers gain a "Boostrap pip?" option:
    * Python Launcher for Windows
    * CPython Windows installer
    * CPython Mac OS X installer

>>>  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.

Agreed, that's why I'm correcting the record now :)

>>>  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.

Yes, an explicit bootstrapping PEP could definitely make a case for
being able to handle that scenario. The reason it's important is that
I really want for us to be able to provide relatively straightforward
instructions to handle the following two cases:

* Tutorials, etc, with unreliable conference and other venue uplinks
(but reasonable local connectivity or just passing USB keys around)
* Remote events where the uplink has a strict download quota, so
minimising bandwidth usage is important

>> 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.

I think a large part of that is the natural disappointment from
thinking we were close to having everything resolved through the
implicit bootstrap mechanism, and then realising that wasn't going to
happen after all and we still have more work to do.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia