On Tue, Mar 30, 2010 at 12:45 AM, Ian Bicking <i...@colorstudy.com> wrote: > 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.
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. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
