[Python-Dev] Bootstrap script for package management tool in Python 2.7 (Was: Re: [Distutils] At least one package management tool for 2.7)
techtonik at gmail.com
Mon Mar 29 15:45:40 CEST 2010
On Mon, Mar 29, 2010 at 12:15 PM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
>> distutils is not a `package management` tool, because it doesn't know
>> anything even about installed packages, not saying anything about
> At this point, no one knows anything about installed packages at the
> Python level.
Users do not care about this, and `distutils` doesn't know this even
at package level.
> Keeping track of installed projects is a feature done within each
> package managment system.
> And the whole purpose of PEP 376 is to define a database of what's
> installed, for the sake of interoperability.
That's great. When it will be ready everybody would be happy to make
their package management tool compliant.
>> `pip` and `distribute` are unknown for a vast majority of Python
>> users, so if you have a perspective replacement for `easy_install` -
> Depending on how you call a Python user, I disagree here. Many people
> use pip and distribute.
> The first one because it has an uninstall feature among other things.
> The second one because it fixes some bugs of setuptools and provides
> Python 3 support
I do not mind if we can distribute three stubs, they will also serve
as pointers for a better way of packaging when an ultimate tool is
finally born. Me personally is willing to elaborate for `easy_install`
stub in 2.7.
>> For now there are two questions:
>> 1. Are they stable enough for the replacement of user command line
>> `easy_install` tool?
>> 2. Which one is the recommended?
>> P.S. Should there be an accessible FAQ in addition to ML?
> This FAQ work has been started in th "HitchHicker's guide to
> Packaging" you can find here:
I can see any FAQ. To me the FAQ is something that could be posted to
distutils ML once a month to reflect current state of packaging. It
should also carry version number. So anybody can comment on the FAQ,
ask another question or ask to make a change.
> Again, any new code work will not happen because 2.7 is due in less
> than a week. Things are happening in Distutils2.
That doesn't solve the problem. Bootstrap script can be written in one
day. What we need is a consensus whatever this script is welcomed in
2.7 or not? Who is the person to make the decision?
> Now, for the "best practice" documentation, I think the guide is the
> best plce to look at.
Let's refer to original user story:
"I installed Python and need a quick way to install my packages on top of it."
"I execute `easy_install something` as said in installation manual,
but nothing/error happens."
>> PEP 376 is completely irrelevant to user side boot package proposal.
> It is, since it proposes an uninstall script called via -m. So having
> a install script called by -m is definitely its business.
The scope of my proposal is a bootstrap script that instructs user how
to install the package management tool of user's choice if this tool
is not yet installed on user system (this is the case with new Python
installation). If you'll come up with a better way of package
management - you will update this bootstrap script with relevant
information in future Python releases.
Right now it is essential to get this _feature_ in Python 2.7 until
2.7 is frozen for new features. The script that shows message upon
invocation and is overwritten by the version of the package it
proposes to install. Is it hard to do?
>> My vision is that decision about having bootstrap package or not in
>> 2.7 should be in python-dev and specific packaging, implementation and
>> pip/distutils/distribute questions in distutils-sig.
> If the mentioned bootstrap script is about a package managment system,
> you should keep the discussion in distutils-SIG I think.
If there will be no bootstrap script in 2.7, I won't have any
motivation to continue discussion until 2.8 deadline is near. Of
course I will be disappointed, because I will have to explain
everything to 2.7 users again and again instead of letting them
execute one command and follow its instructions.
More information about the Python-Dev