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

[Ian Bicking]

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.

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://twitter.com/ianbicking
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100329/af8a9e14/attachment-0001.html>