[Distutils] Using setuptools entry points at Google (and other places...)

Phillip J. Eby pje at telecommunity.com
Tue Jun 26 23:47:29 CEST 2007


At 11:24 PM 6/25/2007 -0700, primco wrote:
>Phillip J. Eby wrote:
> >
> > At 05:45 PM 6/25/2007 -0700, Ben Bangert wrote:
> >>Disclaimer: I don't work at Google, just talk to people who do.
> >>
> >>I know some people at Google that would like to use Pylons there,
> >>unfortunately this isn't quite possible as several parts of Pylons
> >>require setuptools entry points. While setuptools can be installed,
> >>due to Google's packaging system the run-time setuptools environment
> >>has no entry points present, thus it falls down. I'm not sure how
> >>many other companies might also have their own packaging systems that
> >>also incur this problem, but I'm wondering if this can be remedied
> >>somehow.
> >
> > Just make sure that packages' .egg-info directory is installed
> > alongside the code; setuptools will do the rest.  See also:
> >
>
>Thanks Phillip. What's not clear to me is if there is also some versioning
>mechanism. There seems to be two options for naming your egg-info. Let's
>take the package Mako version 0.1.8, as it has a short name.
>
>If I do setup.py install with the --root option, it will install the package
>Mako into the mako directory in my specified location and along side, it
>will create a Mako-0.1.8-py2.4.egg-info directory.
>
>I'm assuming I can have that directory simply named mako.egg-info and remove
>the version info from the filename.

That's correct, but for performance reasons it is NOT 
recommended.  Without the other information in the directory name, 
pkg_resources will have to read the PKG-INFO file at runtime to 
ascertain the package version, and this is then a lot slower than 
just doing a single listdir to get version info for all the projects 
in that directory.  I therefore strongly recommend leaving 
setuptools' naming alone for installed packages.  (For packages in 
development, the performance tradeoff is usually acceptable.)


>Now, in Mako-0.1.8-py2.4.egg-info/top_level.txt is the line 'mako'. Is this
>some sort of pointer to the package?
>
>from the peak website: "....top_level.txt ... lists all top-level modules
>and packages in the distribution. This is used by the easy_install command
>to find possibly-conflicting "unmanaged" packages when installing the
>distribution."
>
>Does this mean that I have a rough version control system where I could
>have, in addition to this plain 'mako' folder that held version 0.1.8, I
>could have a mako-0.1.7 distribution directory with a
>Mako-0.1.7-py2.4.egg-info directory that had the pointer to mako-0.1.7 in
>top_level.txt and setuptools would use this info to find the right version
>of mako?
>
>In this case, if you did 'import mako' in python you'd get mako-0.1.8 but if
>you used setuptools to find the package you could pick from 0.1.8 or 0.1.7?

No.  top_level.txt has only ever been used to check for conflicts 
with non-egg packages, and it's not even used for that any more.  It 
doesn't magically make multi-versioning possible; for 
multi-versioning in a single sys.path directory you have to use .egg 
format (either the zipfile or directory versions).  But if you use 
the .egg format then you can indeed get your pick by using 
pkg_resources to request your desired version(s).

The .egg-info format trades off multi-versioning and some package 
management features in order to provide backward compatibility and/or 
startup performance, which is why it's called "single version, 
externally managed".  You need some sort of package manager to manage 
it, and you don't get multiple versions.



More information about the Distutils-SIG mailing list