[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.
>> >/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
>> >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
>> >One more important thing to know about this setup. We have a couple of
>> >different packages in /base/pkg, and they both contribute to
>> >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
>> > 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
>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?
>>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
>>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
>Since I was following the single-version-externally-managed model with
>an egg-info directory, the egg with the plugin doesn't appear directly
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