[Distutils] [Python-Dev] Bootstrap script for package management tool in Python 2.7 (Was: Re: At least one package management tool for 2.7)

anatoly techtonik techtonik at gmail.com
Wed Jul 7 08:45:17 CEST 2010

On Tue, Mar 30, 2010 at 12:45 AM, Ian Bicking <ianb at colorstudy.com> wrote:
> On Mon, Mar 29, 2010 at 11:26 AM, Larry Hastings <larry at hastings.org> wrote:
>> anatoly techtonik wrote:
>>> So, there won't be any package management tool shipped with Python 2.7
>>> and users will have to download and install `setuptools` manually as
>>> before:
>>>  "search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python
>>> setup.py install"
>>> Therefore I still propose shipping bootstrap package that instruct
>>> user how to download and install an actual package  management tool
>>> when users tries to use it.
>> For what it's worth, Guido prototyped something similar in March of 2008,
>> but his was an actual bootstrapping tool for package management:
>>   http://mail.python.org/pipermail/python-dev/2008-March/077837.html
>> His tool knew how to download a tar file, untar it, and run "python
>> setup.py install" on it.  No version numbers, no dependency management,
>> simple enough that it should be easy to get right.  Only appropriate for
>> bootstrapping into a real package management tool.
>> The thread ends with him saying "I don't have time to deal with this
>> further this week", and I dunno, maybe it just fell off the radar?  I'd been
>> thinking about resurrecting the discussion but I didn't have time either.
> I would consider this bootstrap to be quite workable, though I would add
> that any extra option to the bootstrap script should be passed to setup.py
> install, and the download should be cached (so you can do -h and not have to
> re-download the package once you figure out the extra options -- at least a
> --user option is reasonable here for people without root).  Specifically
> targeting this bootstrap for tools like pip and virtualenv is no problem.
> I think looking around PyPI etc is kind of more than I'd bother with.  Those
> things change, this bootstrap code won't change, it could cause unnecessary
> future pain.  Maybe (*maybe*) it could look in
> http://pypi.python.org/well-known-packages/PACKAGE_NAME and so we can have
> it install a certain small number of things quickly that way -- if the URL
> it looks to is targeted only for the bootstrap script itself then we don't
> have to worry about compatibility problems as much.
> Oh... then i can think of a half dozen other options it could take, and then
> it becomes an installer.  Blech.  OK, I'd be willing to cut off the options
> at --user (which I think is a minimum... maybe --prefix too), and maybe some
> simple package detection so people could write "python -m boostrap
> Setuptools --user" -- entirely based on some well-known URL baked into
> bootstrap.py, where the URL is independent of any other service (and so is
> least likely to cause future problems or ambiguities).
> An advantage to this kind of bootstrapper is that as future packaging
> systems are developed there's a clear way to get started with them, without
> prematurely baking anything in to Python.

The bootstrap should only be a temporary package that will propose
user to automatically install package management tool user is trying
to use if he doesn't have any. It is not Ubuntu-like "missing package
autodetection" - only few most popular non-conflicting packaging
solutions should be bootstrapped in this way:

> python -m easy_install review
`easy_install` is not installed on this system. Do you want to fetch
it to proceed (Y/n)?

Think of it as of one used oriented "1-Click" technology.
anatoly t.

More information about the Distutils-SIG mailing list