Re: [matplotlib-devel] [Numpy-discussion] numpy docs dependency problem in Ubuntu
On Friday, February 11, 2011, Jouni K. Seppänen wrote: > [Crossposting to matplotlib devel list] > > Robert Kern writes: > >> On Thu, Feb 10, 2011 at 11:22, Barry Warsaw 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 > [email protected] > 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 -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Numpy-discussion] numpy docs dependency problem in Ubuntu
On Friday, February 11, 2011, Benjamin Root wrote: > On Friday, February 11, 2011, Jouni K. Seppänen wrote: >> [Crossposting to matplotlib devel list] >> >> Robert Kern writes: >> >>> On Thu, Feb 10, 2011 at 11:22, Barry Warsaw 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 >> [email protected] >> 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 > -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Numpy-discussion] numpy docs dependency problem in Ubuntu
On Feb 11, 2011, at 05:18 PM, Jouni K. Seppänen wrote: >[Crossposting to matplotlib devel list] > >Robert Kern writes: > >> On Thu, Feb 10, 2011 at 11:22, Barry Warsaw 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 signature.asc Description: PGP signature -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Numpy-discussion] numpy docs dependency problem in Ubuntu
>> 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 "", line 1, in
File "/usr/stsci/pyssgdev/2.7/matplotlib/backends/backend_qt.py", line
19, in
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.
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svn ancient history broken
On Thu, Feb 10, 2011 at 5:54 PM, Pauli Virtanen wrote: > On Thu, 10 Feb 2011 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 -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Legend style with axes.hist(histtype='step')
As suggested on http://matplotlib.sourceforge.net/faq/howto_faq.html#submit-a-patch , I have submitted this to the patch tracker an am following it up, with a tracker link! The patch tracker entry is: https://sourceforge.net/tracker/?func=detail&aid=3178834&group_id=80706&atid=560722 Apologies if I am sticking rigidly (and annoyingly) to this process. (I have also been observing the git-transition, so appreciate this probably isn't the best time to integrate random patches) On Mon, Feb 7, 2011 at 1:23 AM, Nicholas Devenish wrote: > One of the things that bugs me about axes.hist is that with > histtype='step' the automatic legend style is an empty box, instead of > a line, as I would expect. This behaviour doesn't seem to make sense, > because it seems a line would be much more appropriate for this case. > Example is attached for the code: > > import matplotlib.pyplot as plt > plt.hist([0,1,1,2,2,2], [0,1,2,3], histtype='step', label="histtype='step'") > plt.legend() > plt.show() > > I can get around this by using proxy Line2D objects in building the > legend, but as this is an extremely common operation for me (the > common style of histograms in my field is equivalent to step) this > becomes messy and annoying. I'd rather not have to roll my own > histogram drawing function, as it would be almost entirely duplicating > the axes hist code, and don't know another way to get what I want. I > understand that the way of setting Legend styles is something that has > been looked at recently, but don't know the timescale for any changes. > > The cause of this is the fact that in axes.py::7799 (current SVN > head), in axes.hist, patch objects are always created, even for the > line-based step style. I searched the tracker briefly, and couldn't > find this mentioned before. I therefore have a few questions: > > - Is this intended behaviour, that I am just not understanding the > requirement for? > - Would changing this to create (and thus return) Line2D's instead of > Patch's for this histtype be a horrible breaking of the return > interface? > > I've attached a patch that makes the simple change of swapping out the > call to .fill for .plot (only the function is changed here, not yet > the documentation), and it appears to work but I haven't tested > exhaustively. > > Thoughts? > > Nick > -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
