On 11/10/09 12:48, Krzysztof Kosiński wrote:
2009/10/11 ~suv <suv-sf@...58...>:
Or could this be handled entirely by the configure and packaging scripts, which then create an updated 'README.python' document included in the 'share/extensions'?
That's definitely not a good idea because globally you'd get thousands of versions of this README file, each one listing different versions, which would create no end of confusion. There's already some dependency checking functionality in the module system that lets you specify that some extension requires an external executable, and if the dependencies are not met the extension is disabled at runtime. I think we should extend that to allow INX files to specify Python dependencies.
Sorry if my brief description of bug #448285 was unclear: it's about the bundled python _modules_ - they cannot be checked as dependency (not in path, no executable) nor exists a reference which versions are bundled with 0.46 and upcoming 0.47. This is an issue mainly on Windows and OS X platforms, because the python modules (and on win32 the python binary itself) are included in the prebuilt packages. However - if an extension developer wants his extension to be used on all platforms he must rely on an agreed min version of python and the two basic modules lxml and numpy, be it on win32 or linux or osx. I think the current dependency check is rather late in the process from a users point-of-view; asking him to update the bundled python-modules in an osx application package to run a specific extension is unrealistic IMHO.
The bug was filed because in the 0.47pre3 packages an apparently rather old version of lxml is included: on Windows v1.3b 2007, on OS X v1.3.6 (for Python 2.5), current version however is v2.2.2.
~suv