Phillip J. Eby wrote: > At 12:48 PM 12/22/2005 +0100, M.-A. Lemburg wrote: >> I'd just wish that this would be the default and the .egg ZIP >> file installation approach be made an option. >> >> setuptools would then finally be compatible to the rest of the >> distutils world again and avoid all the added overhead and >> problems of ZIP file imports. >> >> Perhaps you could have two commands, e.g. the default install >> would create the normal package directory (with added .egg-info >> dir) and a new install_eggfile to install the .egg ZIP file >> instead. > > The only way this could happen is to add a manifest of installed files, > in order to allow uninstallation and upgrades to be made safe in the > absence of a packaging system.
Sure, why not put this manifest into the .egg-info dir ?! The advantage of the .egg-info dir is that it's easy to find using package introspection. > The .egg file/directory technique > currently makes uninstallation as simple as "rm -rf > package-version.egg", and multi-version installs work with no special > action. > > Note, too, that using .egg files or directories means that installation > *never breaks existing programs* as long as they have specified their > dependencies accurately. Traditional distutils installation is > destructive in the absence of a system packager. > > However, if you *have* a system packager, then you should not be using > "setup.py install" anyway, so I'm not sure I see how this is an issue. The issue is that "setup.py install" should continue to install things the (one-and-only) Python way. Any different way should use a different command name. You are currently overloading the install command with a completely different approach, which is not compatible to the standard distutils system or the Python import mechanism. > You should be simply building system packages. And it's quite > straightforward to make most bdist_* commands work: bdist_wininst and > bdist_dumb work with setuptools "out of the box" because they call the > "install" command internally; only bdist_rpm required some > monkeypatching to add --single-version-externally-managed, because it > writes script files that run "install" later. > > Anyway, I guess what I'm saying is, if you want traditional > distutils-style installation, you should use system packages, since > they're the only way to allow uninstallation and avoid corrupted > upgrades. Otherwise, you should use .egg files or directories, in which > case easy_install (and in the future, nest) will be your package manager. I guess what I want to say is that I only want to be forced to use the easy_install package manager (or any other non-system package manager) if I have a need or requirement for the features it offers. The egg format is not too far away from being a nice drop-in format for Python binary extensions. All it takes is: * making sure that an unzip will create a proper Python package (with the meta information embedded into it) With this changes, I think that eggs could actually become a prime distribution format - even for system extensions since it then no longer interferes with the system installer mechanisms. BTW, in case you still don't believe that placing ZIP files on PYTHONPATH causes a slowdown, just install 10-20 eggs on PYTHONPATH and then do a python -v Python will tell you that it scanned all the ZIP files on startup - even before having imported any of the system lib modules such as warnings. Note that disabling the import of site.py doesn't change this (python -S -v). Here's an example with 20 eggs (using C shell): tmp/eggs/> setenv PYTHONPATH egg1.egg:egg10.egg:egg11.egg:egg12.egg:egg13.egg:egg14.egg:egg15.egg:egg16.egg:egg17.egg:egg18.egg:egg19.egg:egg2.egg:egg20.egg:egg3.egg:egg4.egg:egg5.egg:egg6.egg:egg7.egg:egg8.egg:egg9.egg tmp/eggs> time python -S -c '0' 0.014u 0.006s 0:00.02 50.0% 0+0k 0+0io 0pf+0w tmp/eggs> unsetenv PYTHONPATH tmp/eggs> time python -S -c '0' 0.006u 0.003s 0:00.01 0.0% 0+0k 0+0io 0pf+0w System time for startup doubles. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 22 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
