[Patches] [ python-Patches-462936 ] Improved modulefinder

noreply@sourceforge.net noreply@sourceforge.net
Thu, 20 Sep 2001 02:42:07 -0700


Patches item #462936, was opened at 2001-09-19 10:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462936&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improved modulefinder

Initial Comment:
This patch adds two improvements to 
freeze/modulefinder.

1. ModuleFinder now keeps track of which module is 
imported by whom.

2. ModuleFinder, when instantiated with the new 
scan_extdeps=1 argument, tries to track dependencies 
of builtin and extension modules.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2001-09-20 02:42

Message:
Logged In: YES 
user_id=11105

The use case is to find as much dependencies as possible.

Sure, you cannot assume that importing an extension module 
finds all dependencies - only those which are executed 
inside the initmodule function. OTOH, this covers a *lot* 
of problematic cases, pygame and numpy for example.

The situation is (somewhat) similar to finding dependencies 
of python modules - only those donewith normal import 
statements are found, __import__, eval, or exec is not 
handled.

A possible solution would be to run the script 
in 'profiling mode', where the script is actually run, and 
all imports are monitored. This is however far beyond 
ModuleFinder's scope.

Hardcoding the knowledge about dependencies into 
ModuleFinder for the core modules would be possible 
although inelegant IMO. An API for non-standard modules 
would be possible, but how should this be used without 
executing any code?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-09-19 13:28

Message:
Logged In: YES 
user_id=21627

I dislike the chunk on finding external dependencies. What 
is the typical use case (i.e. what module has what 
external dependencies)?

It seems easier to hard-code knowledge about external 
dependencies into ModuleFinder; this hard-coded knowledge 
should cover all core modules. In addition, there should 
be an API to extend this knowledge for non-standard 
modules.

Furthermore, by executing an import, you cannot be sure 
that you really find all dependencies - some may only show 
up when a certain function is used.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462936&group_id=5470