matplotlib-devel Mailing List for matplotlib (Page 5)

On Sat, Jan 02, 2010 at 11:32:00AM +0900, David Cournapeau wrote:
> [snip]
> - supporting different variants of the same package in the
> dependency graph at install time
> [snip]
> The second issue is more challenging. It complicates the dependency
> handling quite a bit, and may cause difficult situations to happen at
> dependency resolution time. This becomes particularly messy if you mix
> packages you build yourself with packages grabbed from a repository. I
> wonder if there is a simpler solution which would give a similar
> feature set.
AFAICT, in Debian, the same feature is given via virtual packages: you
would have:
python-matplotlib
python-matplotlib-basemap
for instance.
It is interesting to note that the same source package may be used to
generate both binary, end-user, packages.
And happy new year!
Gaël

On Fri, Jan 1, 2010 at 10:43 PM, Pierre Raybaut <co...@py...> wrote:
> Hi David,
>
> Following your announcement for the 'toydist' module, I think that
> your project is very promising: this is certainly a great idea and it
> will be very controversial but that's because people expectactions are
> great on this matter (distutils is so disappointing indeed).
>
> Anyway, if I may be useful, I'll gladly contribute to it.
> In time, I could change the whole Python(x,y) packaging system (which
> is currently quite ugly... but easy/quick to manage/maintain) to
> use/promote this new module.
That would be a good way to test toydist on a real, complex package. I
am not familiar at all with python(x,y) internals. Do you have some
explanation I could look at somewhere ?
In the meantime, I will try to clean-up the code to have a first
experimental release.
cheers,
David

Hi all,
I added a recipe for to build a copy of the documentation after every
svn commit. The results may be seen at
http://matplotlib.sourceforge.net/trunk-docs/ (we can change the
location easily if desired).
This is just the result of another buildbot recipe, so any troubles that
crop up when building the docs should trigger an email on the
matplotlib-buildbot mailing list. For now, this is disabled because
compiling the latex document is failing. (Our buildbot is configured to
send email only on the first failure.)
In fact, does anyone know what could be wrong? The last lines of the
LaTeX output are below.
Happy New Year!
-Andrew
Package Fancyhdr Warning: \headheight is too small (12.0pt):
 Make it at least 13.59999pt.
 We now make it that large for the rest of the document.
 This may cause the page layout to be inconsistent, however.
[4]
Chapter 2.
(/usr/share/texmf-texlive/tex/latex/txfonts/ot1txr.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxsya.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxsyb.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxmia.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxsyc.fd)
! Undefined control sequence.
<argument> johnh\PYGZat
 []flag:\textasciitilde []\textgreater [] ipython
-pylab
l.260 ...asciitilde[]@textgreater[] ipython -pylab
?
! Emergency stop.
<argument> johnh\PYGZat
 []flag:\textasciitilde []\textgreater [] ipython
-pylab
l.260 ...asciitilde[]@textgreater[] ipython -pylab
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on Matplotlib.log.

Jae-Joon Lee wrote:
> The error happens because of the *.rst files under doc/examples that
> are not in sync with examples/*.py.
> Removing that directory (doc/examples) will solve the problem (the
> directory will be repopulated when you run make.py again). Here is a
> related link.
> 
> http://old.nabble.com/python-make.py-html-failure-tt26894350.html
Thank you for the quick response. That was it, exactly. There are 
still some example script failures, but nothing that stops the build in 
its tracks.
> 
> Maybe we need something like "python make.py clean"?
Yes, if the generated files can't all land in the "build" directory (as 
would seem preferable), then the next-best thing would be to have 
make.py able to do a thorough cleaning.
Eric
> 
> Regards,
> 
> -JJ
> 
> 
> On Fri, Jan 1, 2010 at 11:09 PM, Eric Firing <ef...@ha...> wrote:
>> I wanted to make a small fix to the contour docstring, and test it
>> before committing, so I tried building the docs from scratch. It fails
>> with the last part of the traceback being:
>>
>> File
>> "/usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py",
>> line 414, in plot_directive
>> options, state_machine)
>> File
>> "/usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py",
>> line 337, in _plot_directive
>> shutil.copyfile(plot_path, os.path.join(destdir, fname))
>> File "/usr/lib/python2.6/shutil.py", line 52, in copyfile
>> fsrc = open(src, 'rb')
>> IOError: [Errno 2] No such file or directory:
>> u'/home/efiring/programs/py/mpl/mpl_trunk/doc/mpl_examples/axes_grid/demo_fixed_size_axes.py'
>> > /usr/lib/python2.6/shutil.py(52)copyfile()
>> -> fsrc = open(src, 'rb')
>>
>> I suspect the problem is that doc/examples/axes_grid has many .rst files
>> for .py scripts that are no longer present, at least on my svn checkout.
>> I have a demo_fixed_size_axes.pyc sitting around, but no corresponding
>> .py, again indicating that the .py was removed from svn.
>>
>> Is there some step I am missing, or is there a need to remove from the
>> svn tree those .rst files that lack corresponding .py?
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>

The error happens because of the *.rst files under doc/examples that
are not in sync with examples/*.py.
Removing that directory (doc/examples) will solve the problem (the
directory will be repopulated when you run make.py again). Here is a
related link.
http://old.nabble.com/python-make.py-html-failure-tt26894350.html
Maybe we need something like "python make.py clean"?
Regards,
-JJ
On Fri, Jan 1, 2010 at 11:09 PM, Eric Firing <ef...@ha...> wrote:
> I wanted to make a small fix to the contour docstring, and test it
> before committing, so I tried building the docs from scratch. It fails
> with the last part of the traceback being:
>
>  File
> "/usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py",
> line 414, in plot_directive
>   options, state_machine)
>  File
> "/usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py",
> line 337, in _plot_directive
>   shutil.copyfile(plot_path, os.path.join(destdir, fname))
>  File "/usr/lib/python2.6/shutil.py", line 52, in copyfile
>   fsrc = open(src, 'rb')
> IOError: [Errno 2] No such file or directory:
> u'/home/efiring/programs/py/mpl/mpl_trunk/doc/mpl_examples/axes_grid/demo_fixed_size_axes.py'
> > /usr/lib/python2.6/shutil.py(52)copyfile()
> -> fsrc = open(src, 'rb')
>
> I suspect the problem is that doc/examples/axes_grid has many .rst files
> for .py scripts that are no longer present, at least on my svn checkout.
> I have a demo_fixed_size_axes.pyc sitting around, but no corresponding
> .py, again indicating that the .py was removed from svn.
>
> Is there some step I am missing, or is there a need to remove from the
> svn tree those .rst files that lack corresponding .py?
>
> Eric
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I wanted to make a small fix to the contour docstring, and test it 
before committing, so I tried building the docs from scratch. It fails 
with the last part of the traceback being:
 File 
"/usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py", 
line 414, in plot_directive
 options, state_machine)
 File 
"/usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py", 
line 337, in _plot_directive
 shutil.copyfile(plot_path, os.path.join(destdir, fname))
 File "/usr/lib/python2.6/shutil.py", line 52, in copyfile
 fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory: 
u'/home/efiring/programs/py/mpl/mpl_trunk/doc/mpl_examples/axes_grid/demo_fixed_size_axes.py'
 > /usr/lib/python2.6/shutil.py(52)copyfile()
-> fsrc = open(src, 'rb')
I suspect the problem is that doc/examples/axes_grid has many .rst files 
for .py scripts that are no longer present, at least on my svn checkout. 
I have a demo_fixed_size_axes.pyc sitting around, but no corresponding 
.py, again indicating that the .py was removed from svn.
Is there some step I am missing, or is there a need to remove from the 
svn tree those .rst files that lack corresponding .py?
Eric

On Thu, Dec 31, 2009 at 6:06 AM, Darren Dale <dsd...@gm...> wrote:
>
> I should defer to the description of extras in the setuptools
> documentation. It is only a few paragraphs long:
>
> http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras-optional-features-with-their-own-dependencies
Ok, so there are two issues related to this feature:
 - supporting variant at the build stage
 - supporting different variants of the same package in the
dependency graph at install time
The first issue is definitely supported - I fixed a bug in toydist to
support this correctly, and this will be used when converting
setuptools-based setup.py which use the features argument.
The second issue is more challenging. It complicates the dependency
handling quite a bit, and may cause difficult situations to happen at
dependency resolution time. This becomes particularly messy if you mix
packages you build yourself with packages grabbed from a repository. I
wonder if there is a simpler solution which would give a similar
feature set.
cheers,
David

Hi David,
Following your announcement for the 'toydist' module, I think that
your project is very promising: this is certainly a great idea and it
will be very controversial but that's because people expectactions are
great on this matter (distutils is so disappointing indeed).
Anyway, if I may be useful, I'll gladly contribute to it.
In time, I could change the whole Python(x,y) packaging system (which
is currently quite ugly... but easy/quick to manage/maintain) to
use/promote this new module.
Happy New Year!
and Long Live Scientific Python! ;-)
Cheers,
Pierre

2009年12月31日 Fernando Perez <fpe...@gm...>:
> On Thu, Dec 31, 2009 at 4:54 AM, Darren Dale <dsd...@gm...> wrote:
>> I have been resistant to committing this patch because (in my opinion)
>> mpl should not have to provide workarounds for bugs in package X on OS
>> Y, distribution Z. I think this particular issue was fixed when
>> PyQt4-4.6.2 was released. But its time to get practical, I suppose.
>> The patch looks fine, I just checked it into the trunk.
>
> Thanks! As the zen goes, practicality beats purity :) I understand
> your reluctance though, it's annoying to pepper mpl's code with this
> kind of junk.
>
> Happy New Year!
>
> f
>
I completely agree. If developers were all doing their "job" in time,
this should not be necessary and Darren's position would be perfectly
right and justified. However, especially on certain open-source
libraries, things are not moving as fast as they should. For example,
in Spyder I had to re-implement a console-oriented text editor widget
with Scintilla-like features because QScintilla's widget had a
performance issue with very long lines (which is almost undectectable
when using it as a simple text editor but it may slow down display
when using it as a console widget). This bug was fixed just a few days
after being reported but there has been no release since then (August
2009). So, to make it work, I had to do this big workaround until the
next release of QScintilla has spread on every platform (i.e. not
until a year I guess). In terms of code refactoring (or purity...),
this was not very satisfying but now Spyder works perfectly because I
stopped saying "it's not my fault, it's QScintilla's".
So even if I agree with Darren on the fact that libraries such as
matplotlib should not provide this kind of workaround, I also think
that -at some point- one has to get practical indeed!
Happy new year guys!
Cheers,
Pierre