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

[Donald Stufft]

On Jul 17, 2013, at 8:40 PM, Daniel Holth <dholth at gmail.com> wrote:
> 
> I didn't realize the current option was about bundling pip itself
> rather than including a simple bootstrap. I have favored the bootstrap
> approach (being any intentionally limited installer that you would be
> daft to use generally). The rationale is that we would want to avoid
> bundling a soon outdated "good enough" tool that people use instead of
> letting better pypi-hosted tools thrive.

Is the argument here that by including pip pre-installed that these other
tools will be unable to compete? Because the same thing could be said
for installing a bootstrapped as well. In fact in either option I expect the
way an alternative installer to be installed would be via ``pip install foo``
regardless of if the person needs to type ``python -mgetpip`` first or not.

> 
> Setuptools is an example of a project that has this problem. Projects
> might use the [even more*] terrible distutils in preference,
> admonishing others to do the same, often without understanding why
> apart from "it's in the standard library".

It's for more reasons than it's in the standard library. setuptools has
had a lot of misfeatures and a good bit of the angst against not using
setuptools was due to easy_install not setuptools itself.

> 
> I didn't believe in the pip command that installs itself because I
> would have been irritated if pip was installed by surprise - maybe I
> have a reason to install it a different way - perhaps from source or
> from a system package.
> 
> A bundled get-pip that avoids also having to install setuptools first,
> and that is secure, and easy to remember, would be super handy.

For the record I'm not against including a method for fetching pip. I
expect Linux distributions to uninstall pip from the Python and it would
still of course be possible to uninstall the provided pip so an easy
method to (re)install it if the users happen to do that and wish to
get it back doesn't seem like a bad idea to me.

> 
> The normal way to get pip these days is to install virtualenv. After
> you get it it's just one command to run and pretty convenient.
> 
> * for the haters
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

Let us not forgot that the pre-installed approach is hardly a new thing
for package managers. Both Ruby and Node do this with their respective
package managers in order to make it simpler for their users to install
packages. So it's been shown that this type of setup can work. Do we
really need extra tedium that users need to do?

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130717/f17a680f/attachment.pgp>