Fw: Q about best practices now (or near future)
Sorry, accidentally left distutils-sig off when replying. ----- Forwarded Message -----
From: Vinay Sajip <vinay_sajip@yahoo.co.uk> To: Nick Coghlan <ncoghlan@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@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
On 18 July 2013 17:44, Vinay Sajip <vinay_sajip@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@yahoo.co.uk> To: Nick Coghlan <ncoghlan@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@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@gmail.com | Brisbane, Australia
participants (2)
-
Nick Coghlan -
Vinay Sajip