Who is maintaining freeze/Modulefinder? I have some issues I would like to discuss... Thomas (Heller)
[Thomas]
Who is maintaining freeze/Modulefinder?
I have some issues I would like to discuss...
[long silence] I guess this make it you then ;-) I wouldn't mind seeing this move into distutils as a module others could draw on. For example, "freeze" could be modifed by the next person game enough to touch it <wink> to reference the module directly in the distutils package? It keeps the highly useful module alive, and makes "ownership" more obvious - whoever owns distutils also gets this baggage <wink> Mark.
[Thomas]
Who is maintaining freeze/Modulefinder?
I have some issues I would like to discuss...
[long silence]
I guess this make it you then ;-)
That's not what I wanted to hear ;-), but anyway, since you answered, I assume you have something to do with it.
I wouldn't mind seeing this move into distutils as a module others could draw on. For example, "freeze" could be modifed by the next person game enough to touch it <wink> to reference the module directly in the distutils package?
It keeps the highly useful module alive, and makes "ownership" more obvious - whoever owns distutils also gets this baggage <wink> Sounds good, but currently I would like to concentrate an technical rather than administrative details.
The following are the ideas: 1. Modulefinder does not handle cases where packages export names referring to functions or variables, rather than modules. Maybe the scan_code method, which looks for IMPORT opcode, could be extended to handle STORE_NAME opcodes which are not preceeded by IMPORT opcodes. 2. Modulefinder uses imp.find_module to find modules, and partly catches ImportErrors. imp.find_module can also raise NameErrors on windows, if the case does not fit. They should be catched. 3. Weird idea (?): Modulefinder could try instead of only scanning the opcodes to actually _import_ modules (at least extension modules, otherwise it will not find _any_ dependencies). Thomas
[Thomas H]
That's not what I wanted to hear ;-), but anyway, since you answered, I assume you have something to do with it.
I stuck my finger in it once :)
1. Modulefinder does not handle cases where packages export names referring to functions or variables, rather than modules. Maybe the scan_code method, which looks for IMPORT opcode, could be extended to handle STORE_NAME opcodes which are not preceeded by IMPORT opcodes.
2. Modulefinder uses imp.find_module to find modules, and partly catches ImportErrors. imp.find_module can also raise NameErrors on windows, if the case does not fit. They should be catched.
They both sound fine to me.
3. Weird idea (?): Modulefinder could try instead of only scanning the opcodes to actually _import_ modules (at least extension modules, otherwise it will not find _any_ dependencies).
There was some reluctance to do this for freeze, and hence Modulefinder was born. I agree it may make sense in some cases to do this, but it shouldn't be a default action. Mark.
participants (2)
-
Mark Hammond -
Thomas Heller