On 20-apr-2006, at 23:08, Martin v. Löwis wrote:
Ronald Oussoren wrote:
As far as I understand the issues they compete up to a point, but should also make it easier to create platform packages that contain proper the proper dependencies because those are part of machine-readable meta-data instead of being written down in readme files. Oddly enough that was also the objection from one linux distribution maintainer: somehow his opinion was that the author of a package couldn't possibly know the right depedencies for it.
What he can't possibly know is the *name* of the package he depends on. For example, a distutils package might be called 'setuptools', so developers of additional packages might depend on 'setuptools'. However, on Debian, the dependency should be different: The package should depend on either 'python-setuptools' or 'python2.3-setuptools', depending on details which are off-topic here.
But when the dependency is written down the platform maintainer, such as the Debian developers, could create a mapping from distutils package names to platform package names. And this could be done using rules instead of a mapping tape (e.g. the platform package is 'python%(pythonver)-% (distutilsname)').
The important bit is that dependencies a present in a machine readable form, and thanks to easy_install you can be pretty sure that these are actually useable.
As for platform packages: not all platforms have useable packaging systems. MacOSX is one example of those, the system packager is an installer and doesn't include an uninstaller. Eggs make it a lot easier to manage python software in such an environment (and please don't point me to Fink or DarwinPorts on OSX, those have serious problems of their own).
Isn't uninstallation just a matter of deleting a directory? If I know that I want to uninstall the Python package 'foo', I just delete its directory. Now, with setuptools, I might have multiple versions installed, so I have to chose (in Finder) which of them I want to delete.
Not always. Several distutils packages install multiple toplevel modules or packages and the names of those aren't always obvious. If they'd use extra_path I could still remove a directory and .pth file, but that option isn't used a lot.
That doesn't require Eggs to be single-file zipfiles; deleting a directory would work just as will (and I believe it will work with ez_install, too).
Egg directories (which are basically just the same as packages using .pth files) also work for this and that's what I usually install. Setuptools can work with python extension inside .zip files, but I'm not entirely comfortable with that.
Package authors will refuse to produce them, putting the burden of package maintenance (what packages are installed, what are their dependencies, when should I remove a package) onto the the end user/system administrator.
Philip has added specific support for them: it is possible to install packages in the tradition way but with some additional files that tell setuptools about installed packages.
As a system administrator, I don't *want* to learn how to install Python packages. I know how to install RPMs (or MSIs, or whatever system I manage); this should be good enough. If "this Python junk" comes with its own installer procedure, I will hate it.
But setuptools doesn't make it impossible to use system packages. As long as those system packages also install the EGG-INFO files packages that make full use of setuptools will be happy as well.
I agree about system packages when I'm in my system administrator role, but when I'm in my developer role it would be very convenient to have cross-platform tools that enable me to quickly install software and tell me what I've got installed.