On Mon, Mar 29, 2010 at 12:15 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
[..]
distutils is not a `package management` tool, because it doesn't know anything even about installed packages, not saying anything about dependencies.
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. -- anatoly t.