[Distutils] pkg_resources get Distribution by module name

[anatoly techtonik]

On Mon, Jan 4, 2010 at 4:18 PM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
>>>>
>>>> If there any way to get Distribution information given the module name
>>>> like 'trac.admin.web_ui'  in setuptools?
>>>>
>>>> There is a problem to extract information about exact distribution
>>>> name and version when module is already imported in application (Trac
>>>> plugins).
>>>
>>> I am not sure exactly what you are trying to do, but :
>>>
>>> If your trac plugin was done using entry points (as it says at
>>> http://trac.edgewall.org/wiki/TracDev/PluginDevelopment), this means
>>> that you can
>>> use the iter_entry_points API from pkg_resources: You will get a
>>> EntryPoint object that contains a dist attribute, pointing to the
>>> distribution infos.
>>
>> Thanks. Already followed this way. Entrypoints is only one way to
>> discover plugins - they will work also if imported directly (there is
>> "plugins" folder in every user site setup). When plugin is imported,
>> everything we have is a name of its class, its module name and path to
>> module file.
>>
>> I need to figure out if given module belongs to any setuptools
>> Distribution to know if it possible to extract any useful information
>> from it to display to user in administration panel.
>
> As long as that "plugins" folder is loaded in your WorkingEnv, you
> could try to see if the module's __file__ path is under the location
> of one distribution listed in the working env.

How can I get the list of distributions for working env?

There is another approach that seems more reliable than entrypoints
and will be used in Trac 0.12 - scanning SOURCES.txt for available
distributions and checking if a given normalized module.__file__ is
present among these choices. If there is no distribution, we still
need a way to detect root package the module is imported from, the
path to the directory of this package and import directory for it.

Scanning SOURCES.txt can be an expensive operation without cache though.

> I can't think of another way. PEP 376 will make this task really
> simple in the future, as you will be able to directly ask for the list
> of distributions that have installed a given file.

List of distributions? Each imported file belongs to one distribution
only. If normalized path belongs to two simultaneously installed
distributions then I doubt I need this "new" system. =)

Considering PEP 376 I apologize for not being able to read it
completely, but as with many PEPs there is one major drawback - no use
cases. For me it should answer four questions:
1. What tasks can not be done currently?
2. What operations are too complicated?
3. What are proposed solutions?
4. What problems should be solved before, during and after PEP implementation?
In the context of my problem I can not see how PEP 376 help with
Python packages installed into PYTHONPATH, .eggs that present in
PYTHONPATH and modules without distribution information. How can it
help to figure out the root package or distribution the imported
module belongs to. Are there any other PEPs for this?

BTW, there is "fils" typo in PEP 376.

-- 
anatoly t.