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. Ronald _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
