matplotlib-devel Mailing List for matplotlib

On Thu, Feb 10, 2011 at 5:54 PM, Pauli Virtanen <pa...@ik...> wrote:
> On 2011年2月10日 17:34:32 -0500, Darren Dale wrote:
> [clip]
>> Unfortunately, I am getting exactly the same results: the matplotlib/
>> directory is missing in the earliest history. I've tried adding
>> --use-cvs and --keep-trivial-imports, to no avail. I've tried checking
>> out a working copy of the cvs repo (setting CVSROOT to point to the
>> directory I created using rsync), and I *thought* the right way to
>> inspect the r7 working directory is to do "cvs update -R -r 7", but
>> thats not right. So I'm currently having trouble determining whether the
>> history even exists in CVS. Anybody have a longer memory than I do? How
>> can I get cvs to perform this basic operation?
>
> Maybe you can try skipping SVN altogether (needs "git-cvs" package on
> Ubuntu):
>
> export CVSROOT=/rsynced/directory
> test -d "$CVSROOT/CVSROOT" || echo "Wrong cvsroot..."
> mkdir imported
> cd imported
> git cvsimport matplotlib
>
> This at least shows some files in the first revisions. You can probably
> then just graft the two histories together at a suitable point.
>
> Apparently, it also needs some use of "git filter-branch" to get rid of
> the top-level matplotlib/ directory.
On further inspection, the direct cvs to git conversion *also* yields
a repository lacking the matplotlib package directory. It looks like
the history leading up to revision 540 may have been lost from the CVS
repository itself, not during the cvs2svn conversion.
John, do you want some time to continue looking into the cvs repo
yourself? Or should we go ahead with the git migration? If the latter,
should we start the git repo at revision 540, or include all available
history, even though some of it is missing the matplotlib package
directory? If we want to go ahead with the git migration, I can
probably work on it this weekend.
Darren

>> We can't put python-matplotlib in main because of *its* dependencies.
>> 
>
> As a digression, I think the python-matplotlib dependencies could be
> significantly reduced. For a number of use cases (this is one of them,
> but there are others), you don't need any GUI backend. Independent of
> this issue, it would be great to be able to install python-matplotlib
> in a headless server environment without pulling in all of those GUI
> bits. Looking at the list of the hard dependencies, I don't understand
> why half of them are there.
>
> http://packages.ubuntu.com/natty/python/python-matplotlib
> 
This web page lists several "dependencies" that are optional. Just 
flipping through the list, I can see several packages that I know that I 
do not have, and several more that I have never heard of. "Never heard 
of" could mean that it is in my linux distro and I don't know it, but I 
am certain that I have machines that do not have cairo or gtk+ or qt.
A matplotlib application selects one of the available backends to draw 
the graphics. If I remember correctly _all_ backends are optional in 
matplotlib, but there is at least one ("agg") that is available everywhere.
When you install matplotlib, it builds support for any backends that it 
can. A backend that depends on a missing library does not get a C 
extension built. BUT the python code is still installed. The only way 
to know that a backend is not supported in this installation is to try 
to use it.
For example,
 >>> import matplotlib.backends.backend_qt
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/stsci/pyssgdev/2.7/matplotlib/backends/backend_qt.py", line 
19, in <module>
 raise ImportError("Qt backend requires pyqt to be installed.")
ImportError: Qt backend requires pyqt to be installed.
 >>>
Ok - I don't have qt on this machine.
So, you can try this: Get a build machine that has all the packages 
required by the various backends. Build a binary distribution of 
matplotlib. Install it on a machine that has only some of the libraries 
required by the backends.
The result is a copy of matplotlib with _some_ working backends and some 
that fail because of missing libraries. As you install other supporting 
packages, additional backends can start working because their shared 
library is now present.
So, if I install matplotlib and pyqt is not there I get a working 
matplotlib without QT support. If I use a package installer to install 
pyqt, presumably it will also install the QT libraries, resulting in 
matplotlib that does have qt support.
I'm not saying you want to do this, but it is an option. If you want to 
experiment in this direction, there is a list that breaks out 
requirements for the core and requirements for each of the backends at 
http://matplotlib.sourceforge.net/users/installing.html .
Mark S.

On Feb 11, 2011, at 05:18 PM, Jouni K. Seppänen wrote:
>[Crossposting to matplotlib devel list]
>
>Robert Kern <rob...@gm...> writes:
>
>> On Thu, Feb 10, 2011 at 11:22, Barry Warsaw <ba...@py...> wrote:
>>
>>> Here's the problem: for Ubuntu, we've had to disable the building of
>>> the numpy documentation package, because its dependencies violate
>>> Ubuntu policy. Numpy is in our "main" archive but the documentation
>>> depends on python-matplotlib, which lives in our "universe"
>>> archive. Such cross archive dependencies break the build.
>>>
>>> We can't put python-matplotlib in main because of *its* dependencies.
>>
>> As a digression, I think the python-matplotlib dependencies could be
>> significantly reduced. For a number of use cases (this is one of them,
>> but there are others), you don't need any GUI backend. Independent of
>> this issue, it would be great to be able to install python-matplotlib
>> in a headless server environment without pulling in all of those GUI
>> bits. Looking at the list of the hard dependencies, I don't understand
>> why half of them are there.
>>
>> http://packages.ubuntu.com/natty/python/python-matplotlib
>
>Would it make sense to split out each interactive backend to its own
>Ubuntu package, e.g. python-matplotlib-tk, etc? Each of these would
>depend on the relevant toolkit packages, and python-matplotlib would
>have a much shorter list of dependencies.
Note that the main/universe distinction happens at the source package level,
so we'd have to have separate source packages, ideally with different upstream
tarballs. We could finesse that with two different source packages using the
same upstream tarball (as suggested in a previous follow up), but I think it
would be more difficult to get into Debian, thus precipitating a divergence.
Cheers,
-Barry

On Friday, February 11, 2011, Benjamin Root <ben...@ou...> wrote:
> On Friday, February 11, 2011, Jouni K. Seppänen <jk...@ik...> wrote:
>> [Crossposting to matplotlib devel list]
>>
>> Robert Kern <rob...@gm...> writes:
>>
>>> On Thu, Feb 10, 2011 at 11:22, Barry Warsaw <ba...@py...> wrote:
>>>
>>>> Here's the problem: for Ubuntu, we've had to disable the building of
>>>> the numpy documentation package, because its dependencies violate
>>>> Ubuntu policy. Numpy is in our "main" archive but the documentation
>>>> depends on python-matplotlib, which lives in our "universe"
>>>> archive. Such cross archive dependencies break the build.
>>>>
>>>> We can't put python-matplotlib in main because of *its* dependencies.
>>>
>>> As a digression, I think the python-matplotlib dependencies could be
>>> significantly reduced. For a number of use cases (this is one of them,
>>> but there are others), you don't need any GUI backend. Independent of
>>> this issue, it would be great to be able to install python-matplotlib
>>> in a headless server environment without pulling in all of those GUI
>>> bits. Looking at the list of the hard dependencies, I don't understand
>>> why half of them are there.
>>>
>>>  http://packages.ubuntu.com/natty/python/python-matplotlib
>>
>> Would it make sense to split out each interactive backend to its own
>> Ubuntu package, e.g. python-matplotlib-tk, etc? Each of these would
>> depend on the relevant toolkit packages, and python-matplotlib would
>> have a much shorter list of dependencies.
>>
>> --
>> Jouni K. Seppänen
>> http://www.iki.fi/jks
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> Num...@sc...
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
> There are a lot of advantages to this idea, and I wonder if it might
> make distributions easier and allow fuller control by the user. In
> particular, kubuntu could default to using the qt backend while
> regular ubuntu could use gym.
stupid autocorrect... Gym -> Gtk
Ben Root
>
> However, how practical is this to implement? What does it require
> from us upstream?
>
> Ben Root
>

On Friday, February 11, 2011, Jouni K. Seppänen <jk...@ik...> wrote:
> [Crossposting to matplotlib devel list]
>
> Robert Kern <rob...@gm...> writes:
>
>> On Thu, Feb 10, 2011 at 11:22, Barry Warsaw <ba...@py...> wrote:
>>
>>> Here's the problem: for Ubuntu, we've had to disable the building of
>>> the numpy documentation package, because its dependencies violate
>>> Ubuntu policy. Numpy is in our "main" archive but the documentation
>>> depends on python-matplotlib, which lives in our "universe"
>>> archive. Such cross archive dependencies break the build.
>>>
>>> We can't put python-matplotlib in main because of *its* dependencies.
>>
>> As a digression, I think the python-matplotlib dependencies could be
>> significantly reduced. For a number of use cases (this is one of them,
>> but there are others), you don't need any GUI backend. Independent of
>> this issue, it would be great to be able to install python-matplotlib
>> in a headless server environment without pulling in all of those GUI
>> bits. Looking at the list of the hard dependencies, I don't understand
>> why half of them are there.
>>
>>  http://packages.ubuntu.com/natty/python/python-matplotlib
>
> Would it make sense to split out each interactive backend to its own
> Ubuntu package, e.g. python-matplotlib-tk, etc? Each of these would
> depend on the relevant toolkit packages, and python-matplotlib would
> have a much shorter list of dependencies.
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
>
> _______________________________________________
> NumPy-Discussion mailing list
> Num...@sc...
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
There are a lot of advantages to this idea, and I wonder if it might
make distributions easier and allow fuller control by the user. In
particular, kubuntu could default to using the qt backend while
regular ubuntu could use gym.
However, how practical is this to implement? What does it require
from us upstream?
Ben Root