On Wed, Apr 15, 2009 at 5:40 AM, Kevin Teague wrote:

-1 for install/uninstall scripts in Distutils

I'd argue that the scope of Distutils is already wide enough that it doesn't need to be extended to also be a "package manager" -- even if it's a really simple one.

If a install/uninstall tool does go into Python, I'd rather see it as something like 'simplepackageinstaller.install' instead of 'Distutils.scripts.install'. This would also make it more clear that this tool is simply working with the standard packaging formats and tools, and doesn't muddy the format/implementation as much as if it's just another part of Distutils.

But then I don't think Python should have a built-in installer or package manager. There are excellent tools already available (Buildout, pip, dpkg, RPM), it would be better if we guided people to these tools and let them pick the right one for their installation use case.

I wouldn't put zc.buildout in the same level than pip or easy_install. and I guess what we would have in DIstutils would be quite similar to what easy_install or pip offers.

If there was a installer, I'm assuming it'd be quite a simple one - e.g. installs single-version into site-packages. This caters to well to casual user -- they can just run a "standard" command out-of-the-box and take-off running with a distribution, but it also teaches them bad habits (e.g. that you want to be commonly installing into site-packages or that you want to develop your own code without properly expressing it's dependencies). When they want to use better development practices, they'll have to switch to a "non-standard" tools to do "non-standard" installations.

For the "site-package" part, this is true, but so wrong. Many people in this mailing list (and in real life) agrees that it's wrong to install a package in site-packages. So basically you are saying that a fresh Python installation teaches people bad habits because they end up installing packages in site-packages. And that they should install third party packages to have better practices. (eg like virtualenv or zc.buildout) It doesn't sound right. Imho Python shoulld provide multiple versions for the same package. and change its importer. -- Tarek Ziadé | http://ziade.org

On Fri, Apr 17, 2009 at 12:08:22AM +0200, Tarek Ziadé wrote:

On Wed, Apr 15, 2009 at 5:40 AM, Kevin Teague wrote:

...

If there was a installer, I'm assuming it'd be quite a simple one - e.g. installs single-version into site-packages. This caters to well to casual user -- they can just run a "standard" command out-of-the-box and take-off running with a distribution, but it also teaches them bad habits (e.g. that you want to be commonly installing into site-packages or that you want to develop your own code without properly expressing it's dependencies). When they want to use better development practices, they'll have to switch to a "non-standard" tools to do "non-standard" installations.

For the "site-package" part, this is true, but so wrong. Many people in this mailing list (and in real life) agrees that it's wrong to install a package in site-packages.

Half of those people say that it's wrong to install into /usr/lib/pythonX.Y/site-packages (because /usr belongs to apt/rpm) but fine to install into /usr/local/lib/pythonX.Y/site-packages. The other half say that it's always wrong to install globally, since you may want to use different sets of packages for different purposes. Marius Gedminas -- To err is human, but to really foul things up requires a computer.

At 09:13 AM 4/15/2009 +0200, Matthias Klose wrote:

Tarek Ziadé schrieb:

...

Hello

I am working on PEP 376 http://svn.python.org/projects/peps/trunk/pep-0376.txt, and there's a part about adding an install and uninstall script into Distutils.

according to the PEP files mentioned in RECORD are relative paths, which follows the assumption that everything is contained in the .egg directory. A new PEP should not assume this, but support the installation into a FHS layout as well (e.g. as done by (Linux) distributions).

Actually, the assumption is that everything is relative to site-packages in a flat install. Scripts and data should be able to use absolute paths, however. The main purpose of the recommendation is that anything installed relative to the target directory (typically site-packages) should use a relative path, so that simple installations are relocatable and have cross-platform-compatible path information, for use cases where a single installation of code is shared between e.g. Windows, OS X, and Linux.