[Distutils] problem finding an entry point

Phillip J. Eby pje at telecommunity.com
Wed Sep 6 16:18:05 CEST 2006

At 09:00 AM 9/6/2006 -0400, Kevin Dangoor wrote:
>On 9/6/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>>At 01:07 PM 9/5/2006 -0700, Kevin Dangoor wrote:
>> >On 9/1/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>> >>I think you're going to need to be more specific here.  I'm not clear on
>> >>what is being found when, by what.  I'm also not clear what is being
>> >>symlinked where.
>> >
>> >OK, here are specifics....
>> >
>> >Things in /base/pkg/Foo/usr/local/lib/python2.4/site-packages are
>> >linked over to /usr/local/lib/python2.4/site-packages. (I doubt it
>> >makes a difference, but this whole thing is actually run in a chrooted
>> >environment...) It appears that in most instances (and I don't know
>> >enough about the packager to know which instances and why), the
>> >directories are real directories, but the files inside are symlinks.
>> >Specifically:
>> >
>> >/usr/local/lib/python2.4/site-packages/nose would be a real directory
>> >/usr/local/lib/python2.4/site-packages/nose/result.py is a symlink to
>> >/base/pkg/Foo/usr/local/lib/python2.4/site-packages/nose/result.py
>> >
>> >There's a nose-0.9.0-py2.4.egg-info directory next to the nose
>> >directory (again, the directory is real but the files inside are
>> >symlinks).
>> >
>> >One more important thing to know about this setup. We have a couple of
>> >different packages in /base/pkg, and they both contribute to
>> >/usr/local/lib...
>> >
>> >When you run python, the /baes/pkg... path for the package that
>> >contains Python is what shows up in sys.path (not
>> >/usr/local/lib/python2.4/site-packages). We created a sitecustomize.py
>> >file to add /usr/local/lib/python2.4/site-packages as a sitedir. We're
>> >able to import all of the python packages from that directory just
>> >fine. But, I wrote a nose plugin that is only found if I explicitly
>> >set a PYTHONPATH environment variable to point to
>> >/usr/local/lib/python2.4/site-packages.
>> >
>> > From the Python prompt, if I iter_entry_points, I don't see my plugin
>> >without the PYTHONPATH. However, I can require my package and see the
>> >entry point via the API.
>> >
>> >Hopefully that makes it clearer...
>>Not by much, I'm afraid.  You haven't answered these questions:
>>* Is the plugin on sys.path?
>Yes. Twice it turns out... It first appears in the
>/base/pkg/MainPackage/usr/local/lib/python2.4/site-packages location,
>and then the symlinked one (mentioned in my earlier message) appears
>in /usr/local/lib/python2.4/site-packages which is added to sys.path
>via sitecustomize (site.addsitedir). Running "python" from the command
>line and looking at sys.path shows both of these locations.
>(Note that Nose itself appears in /base/pkg/DevPackage/... and is then
>symlinked into the /usr/local/lib... space, the locations above are
>the ones for my Nose plugin.)
>>* How is the plugin installed?  Develop?  .egg?  .egg-info?
>this may be relevant... the python package is called something like
>"foobar" and the egg-info is "FOOBar-1.0-py2.4.egg-info". As I
>mentioned, pkg_resources is able to find it.
>>* Where is it installed?
>see above
>>Note that a plugin has to be on sys.path for its entry points to show up,
>>so it almost sounds to me like there's no problem here and everything is
>>behaving normally.
>>What would be weird would be if it *did* show in iter_entry_points
>>*without* being on sys.path, or if it were on sys.path, but not showing up
>>in iter_entry_points.
>Since I was following the single-version-externally-managed model with
>an egg-info directory, the egg with the plugin doesn't appear directly
>on sys.path.

Huh?  Above you said it did.  Which is it?

Maybe you should do this:

 >>> import pkg_resources
 >>> print list(pkg_resources.working_set)
 >>> print sys.path

And send me the result.

>  Here's the kicker, though, if I set the PYTHONPATH
>environment variable to /usr/local/lib/python2.4/site-packages the
>plugin does show up in iter_entry_points. Doing that has the effect of
>putting the /usr/local/lib... symlinked version before the "real"
>version in /base/pkg/MainPackage on the sys.path.
>Also, I'm effectively running as root, so there shouldn't be any
>permissions issues involved.

That's not likely the problem.  pkg_resources does a lot of 
os.realpath()-ing to ensure it's using canonical paths; it's more likely 
that there's some place where the difference between the "real" path and 
the version that's on sys.path is causing a problem.  Assuming, of course, 
that there is in fact a problem, which I'm not yet convinced of because 
your statements above appear inconsistent, although that's probably because 
you're using more than one definition of what "on sys.path" means.

More information about the Distutils-SIG mailing list