[Python-ideas] Add a site.cfg to keep a persistent list of paths
p.f.moore at gmail.com
Wed Oct 20 16:00:54 CEST 2010
On 20 October 2010 14:36, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
> It goes a little bit farther than than: the project packages and
> modules have to be found in the path, but we also need to publish the
> project metadata that would be installed in a normal installation, so
> our browsing/query APIs can find the project.
Maybe I'm still missing something, but are you saying that the
metadata query APIs don't respect PYTHONPATH? Is there are reason why
> So, if a project 'Boo' has two packages 'foo' and 'bar' and a module
> 'baz.py', we need those in the path but also the Boo.dist-info
> directory that is created at installation time (see PEP 376).
> Setuptools' metadata directory is called Boo.egg-info, and distutils 1
> has a file called Boo.egg-info since python 2.5
... and I'd expect the dist-info directory to be located by searching PYTHONPATH
> And since a python project can publish several top level directories,
> all of them needs to be added in the path. so adding the current dir
> to PYTHONPATH will not work in every case even if the metadata are
> built and dropped there.
So, project Foo publishes packages bar and baz.
(Is that right? I'm rusty on the structure. That's how it looks in Python 2.7)
So the directory MyDir is on PYTHONPATH. Then Foo.bar and Foo.baz are
visible, and the dist-info file is on PYTHONPATH for introspection.
If you're saying that Foo *isn't* a package itself, so Foo/__init__.py
doesn't exist, and bar and baz should be visible unqualified, then I
begin to see your issue (although my first reaction is to say "don't
do that, then" :-)). But don't you then just need to search *parents*
of elements of PYTHONPATH as well for the metadata search? If that's
an issue then doesn't that mean you've got other problems with how
people structure their directories? Actually, I suspect my picture
above is wrong, as I can't honestly see that mandating that the
dist-info file be a *sibling* (in an arbitrarily cluttered directory)
of the project directory, is sensible...
But I'm probably not seeing the real issues here.
All I would say is, don't let the needs of more unusual configurations
over-complicate basic usage.
More information about the Python-ideas