Extracting python dependencies automatically

[Panu Matilainen]

On Wed, 15 Aug 2007, Jeff Spaleta wrote:

> On 8/15/07, Panu Matilainen <pmatilai at redhat.com> wrote:
>> For requires, try to locate any python scripts and modules and for each
>> found, run them through python's modulefinder which attempts to figure out
>> which modules a script/module uses. Then, based on the filenames gotten
>> from modulefinder results, turn them into python(<name>) entries, for
>
>> Thoughts / comments?
>
> Do you have any mechanism to distinguish optional modules from hard
> requirement modules? Some python applications will test for the
> availability of a module through a via an exception test for optional
> features and then gracefully continue if its not available.

That's the problem with interpreted languages - there's no way to get it 
100% right, see below...

> Looking 20 minutes into the future, is this aimed at into rpmbuild's
> automatic dependancy generation scripts?

That's the idea of course, but I doubt that's going to happen in time for 
F8.

The big problem with using modulefinder is that it expects to be able to 
actually import the modules. That might work fairly ok for the occasional 
"rpmbuild -bb my.spec" use on developers host, but in minimal 
buildroots... to satisfy that, the manual Requires turn into 
BuildRequires, so much for automatic dependencies. In other words, the 
current pythondeps.py is totally useless in real world :)

It gets worse from here. Things are fairly straightforward as long as 
we're only talking about modules in standard locations (either things in 
python standard library or site-packages) but what about cases where the 
software uses a custom path to import private modules (eg yum importing 
stuff from /usr/share/yum-cli)? Since you can't verify if something is in 
site-packages (because you can't assume them being installed on minimal 
buildroot), there's no way to know if import A is on private or public 
module. It's possible to look through the filenames and see if 
there are matching *.py[co] files in non-standard locations and assume 
they're just private modules but there is some room for error in there.

 	- Panu -