[Python-Dev] Internal documentation for egg formats now available

Phillip J. Eby pje at telecommunity.com
Fri Apr 28 19:51:32 CEST 2006


(Thank you, by the way, for actually reading some of the documentation 
before writing this post, and for asking questions instead of jumping to 
conclusions.)


At 06:43 PM 4/28/2006 +0200, M.-A. Lemburg wrote:
>I've now found this section in the documentation which seems to
>have the reason:
>
>http://peak.telecommunity.com/DevCenter/EasyInstall#compressed-installation
>
>Apart from the statement "because Python processes zipfile entries on
>sys.path much faster than it does directories." being wrong,

Measure it.  Be sure to put the directories or zipfiles *first* on the 
path, not last.  The easiest way to do so accurately would be to 
easy_install some packages first using --zip-ok and then using 
--always-unzip, and compare the two.

Finally, try installing them --multi-version, and compare that, to get the 
speed when none of the packages are explicitly put on sys.path.


>it looks like all you'd have to do, is make --always-unzip the
>default.

You mean, all that *you'd* have to do is put it in your distutils 
configuration to make it the default for you, if for some reason you have a 
lot of programs that resemble "python -c 'pass'" in their import behavior.  :)


>Another nit which seems to have been introduced in 0.6a11:
>you now prepend egg directory entries to other sys.path entries,
>instead of appending them.
>
>What's the reason for that ?

It eliminates the possibility of conflicts with system-installed packages, 
or packages installed using the distutils, and provides the ability to 
install stdlib upgrades.


>Egg directory should really be treated just like any other
>site-package package and not be allowed to override stdlib
>modules and packages

Adding them *after* site-packages makes it impossible for a user to install 
a local upgrade to a system-installed package in site-packages.

One problem that I think you're not taking into consideration, is that 
setuptools does not overwrite packages except with an identical 
version.  It thus cannot replace an existing "raw" installation of a 
package by the distutils, except by deleting it (which it used to support 
via --delete-conflicting) or by installing ahead of the conflict on sys.path.

Since one of the problems with using --delete-conflicting was that users 
often don't have write access to site-packages, it's far simpler to just 
organize sys.path so that eggs always take precedence over their parent 
directory.  Thus, eggs in site-packages get precedence over site-packages 
itself, and eggs on PYTHONPATH get precedence over PYTHONPATH.


>without explicit user action by
>e.g. adjusting PYTHONPATH.

Installing to a PYTHONPATH directory *is* an explicit user 
action.  Installing something anywhere is an explicit user request: "I'd 
like this package to be importable, please."  If you don't want what you 
install to be importable by default, use --multi-version, which installs 
packages but doesn't put them on sys.path until you ask for them at runtime.



More information about the Python-Dev mailing list