[Distutils] problem finding an entry point

[Phillip J. Eby]

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?
>
>.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.