It looks like we're on the hook for some bugs associated with our use of setuptools... I'm forwarding an email from the distutils-sig.
The short of it is that Phillip Eby suggests we move matplotlib.toolkits to matplotlib_toolkits to save ourselves some grief. This does seem easier than the apparent alternative -- moving everything out of matplotlib/__init__.py.
-Andrew
Re: [Distutils] Confusion about the effect of eggs onimport (4.29 KB)
I'll fess up that I added the setuptools namespace support for the
toolkits. Keep in mind I did this a LONG time ago, and as implied
below the docs were sketchy. It did work at the time, but I honestly
have not had basemap installed in a while to see the breakage.
Charlie
On 2/9/07, Andrew Straw <strawman@...36...> wrote:
It looks like we're on the hook for some bugs associated with our use of
setuptools... I'm forwarding an email from the distutils-sig.The short of it is that Phillip Eby suggests we move matplotlib.toolkits
to matplotlib_toolkits to save ourselves some grief. This does seem
easier than the apparent alternative -- moving everything out of
matplotlib/__init__.py.-Andrew
---------- Forwarded message ----------
From: "Phillip J. Eby" <pje@...506...>
To: skip@...503..., distutils-sig@...147...
Date: Fri, 09 Feb 2007 19:20:31 -0500
Subject: Re: [Distutils] Confusion about the effect of eggs on import
At 05:30 PM 2/9/2007 -0600, skip@...503... wrote:
>(I'm sending this to distutils because I have this vague notion that the
>problem might have something to do with setuptools or eggs on sys.path.)Their mere presence on sys.path doesn't do anything, if you're not
importing pkg_resources or importing anything from inside the eggs.However, matplotlib imports pkg_resources and is a (broken) namespace package.
>We have a weird issue trying to import matplotlib at work.
I investigated a little, and here's what's happening. Matplotlib declares
'matplotlib.toolkits' as a namespace package, but you can't make a child
package a namespace package without the parent being one too. A namespace
package combines all packages on sys.path with the same name into a single
package.So here's what's happening. When setuptools is on sys.path, then importing
matplotlib causes it to declare its namespace, which merges all copies of
matplotlib on sys.path into a single super-package -- and invokes all the
__init__.py's.When setuptools is not on sys.path, the attempt to declare the namespace
fails (it's wrapped in a try/except in matplotlib/__init__.py), so nothing
else happens.There are, I think, two problems here. One, is that setuptools shouldn't
be executing multiple __init__.py's for a package, but for backward
compatibility reasons this isn't being dropped until 0.7a1. Two, is that
setuptools currently allows you to declare a child namespace package (like
'matplotlib.toolkits') without explicitly declaring the parent to be a
namespace package. So, sometimes people declare a subpackage without
realizing the parent will also have to be treated as a namespace package.As a result, they end up thinking that they can include initialization code
in the parent package, when in fact there are many circumstances where it
simply won't work. In this case, matplotlib/__init__.py contains
executable code, which is a no-no for a namespace package.My suggestion would be that matplotlib use a matplotlib_toolkits namespace
package, rather than attempting to keep matplotlib.toolkits, since it
appears they are relying on a substantial amount of code living in the
__init__.py.In short, the problem is a matplotlib bug, but in fairness it's probably
due to the sketchy documentation surrounding the proper care and feeding of
namespace packages, coupled with the implicit declaration of namespace
packages. All of the problems are explained in the setuptools
documentation, but unfortunately that's not the same as anybody being able
to figure out that the problems will apply to THEM._______________________________________________
Distutils-SIG maillist - Distutils-SIG@...147...
Mailman 3 Info | distutils-sig@python.org - python.org-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
I could go either way -- we are going to break a lot of code no matter
which way we do it. Ironically, and via a circuitous path, this is
ultimately my problem. The problem Phil is discussing was raised by
Skip on the distutils list. Skip works with me and is trying to
diagnose an MPL install problem I encountered at work yesterday and
asked for his input on.
I am inclined to consider ripping out the __init__ stuff into a
"config" module or something like that. The reason is that every time
someone wants to use matplotlib as a library, eg to import a single
function from matplotlib.cbook, they have to pay for the entire
__init__load including the rc parse, even though cbook doesn' use
anything else from the rest of matplotlib. It only depends on the
standard library. So there is at least one additional reason to move
the stuff from __init__ out. I also like the ability to use eggs to
have mpl namespace packages, eg toolkits.
So if ease-of-implementation is the only argument against ripping out
the __init__ stuff I don't find it compelling (I'll be happy to do it)
but if there are other reasons to leave __init__ as is let's hear
them.
JDH
On 2/9/07, Andrew Straw <strawman@...36...> wrote:
It looks like we're on the hook for some bugs associated with our use of
setuptools... I'm forwarding an email from the distutils-sig.
The short of it is that Phillip Eby suggests we move matplotlib.toolkits
to matplotlib_toolkits to save ourselves some grief. This does seem
easier than the apparent alternative -- moving everything out of
matplotlib/__init__.py.
John Hunter wrote:
I am inclined to consider ripping out the __init__ stuff into a
"config" module or something like that.
+1
