On Mon, Mar 29, 2010 at 11:26 AM, Larry Hastings <la...@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
