Darren Dale wrote: > On Thursday 13 December 2007 2:22:13 pm Robert Kern wrote: >> John Hunter wrote: >>> Do we need namespace packages in toolkits? I recently added gtktools >>> and exceltools to toolkits, and got a very hard to debug error: >>> >>> In [1]: import matplotlib >>> >>> In [2]: matplotlib.__file__ >>> Out[2]: >>> '/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/__init__.py >>> c' >>> >>> In [3]: matplotlib.rcParams['axes.axisbelow'] >>> Out[3]: False >>> >>> In [4]: import matplotlib.toolkits.gtktools >>> >>> In [5]: matplotlib.__file__ >>> Out[5]: >>> '/opt/app/g++lib6/python-2.4/lib/python2.4/site-packages/matplotlib/__ini >>> t__.pyc' >>> >>> In [6]: matplotlib.rcParams['axes.axisbelow'] >>> ------------------------------------------------------------ >>> Traceback (most recent call last): >>> File "<ipython console>", line 1, in ? >>> KeyError: 'axes.axisbelow' >>> >>> Notice that the matplotlib module which was previously imported got >>> changed by the import of the toolkit which declared itself a namespace >>> package. Now this may be the result of mpl not using namespace >>> packages correctly (eg matplotlib/__init__.py should be empty save for >>> the namespace package or something like that) >> Probably. In setuptools 0.7, they can have stuff in them, but all of them >> must be identical. > > How would one learn about this new feature? According to setuptools.txt from > the 0.7 svn checkout, the namespace package's __init__.py must still be empty > save the namespace declaration.
It's a logical consequence of how namespace packages are loaded in 0.7 as has been explained on the mailing list whenever the subject of namespace packages in 0.7 is brought up. It's still not recommended, but it can be made to work. The remaining objection in the documentation is about installing the package using --single-version-externally-managed for distro packagers. Using --svem, the __init__.py files are not installed. Since a distro package would have a mynamespace-common package (or something similar) that *just* provides this __init__.py file for all of the mynamespace.foo packages, it can provide the single copy of the meaningful code. But it's still not a good idea. >> If you are using an unmodified matplotlib/__init__.py in >> the main matplotlib package, then the "if 0:" is preventing the declaration >> of the namespace package, and that may be contributing. >> >> Also, neither matplotlib nor matplotlib.toolkits is named as a >> namespace_package in matplotlib's setup.py, and both have to be. Similarly, >> basemap (for example) only lists matplotlib.toolkits but not matplotlib. > > If I understand correctly, even after fixing these two problems, namespace > packages would not work since matplotlib/__init__.py contains lots of > meaningful code. Based on the remarks at > http://mail.python.org/pipermail/distutils-sig/2007-October/008346.html and > the setuptools svn commit log, it looks like development on version 0.7 is > not a priority and a release in the next year is unlikely. So is it fair to > say that for the foreseeable future, matplotlib is not compatible with > namespace packages unless we cleaned out __init__.py? Yes. Phillip explained this in February and suggested a way around the issue: http://www.mail-archive.com/[EMAIL PROTECTED]/msg02908.html -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
