matplotlib-devel Mailing List for matplotlib

Andrew Straw wrote:
> Andrew Straw wrote:
> 
>> In fact, does anyone know what could be wrong? The last lines of the
>> LaTeX output are below.
>> 
>> 
> OK, this cropped up on another buildbot for another project of mine --
> it looks with a Sphinx dependency, Pygments 1.2.1 (just released), there
> is some issue that wasn't there with Pygments 1.1.1. I'll try to isolate
> the issue and report it to the appropriate tracker, but at this point I
> don't think it's an MPL issue.
> 
For the record, I reported it here:
http://dev.pocoo.org/projects/pygments/ticket/463

Andrew Straw wrote:
> In fact, does anyone know what could be wrong? The last lines of the
> LaTeX output are below.
> 
OK, this cropped up on another buildbot for another project of mine --
it looks with a Sphinx dependency, Pygments 1.2.1 (just released), there
is some issue that wasn't there with Pygments 1.1.1. I'll try to isolate
the issue and report it to the appropriate tracker, but at this point I
don't think it's an MPL issue.
-Andrew

David Cournapeau wrote:
> On Sat, Jan 2, 2010 at 4:58 PM, Gael Varoquaux
> <gae...@no...> wrote:
> 
>> 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:
>> 
>
> I don't think virtual-packages entirely fix the issue. AFAIK, virtual
> packages have two uses:
> - handle dependencies where several packages may resolve one
> particular dependency in an equivalent way (one good example is
> LAPACK: both liblapack and libatlas provides the lapack feature)
> - closer to this discussion, you can build several variants of the
> same package, and each variant would resolve the dependency on a
> virtual package handling the commonalities. For example, say we have
> two numpy packages, one built with lapack (python-numpy-full), the
> other without (python-numpy-core). What happens when a package foo
> depends on numpy-full, but numpy-core is installed ?
When you type "apt-get install my_new_package", the version resolution
system will tell you that apt-get will remove python-numpy-core and will
install python-numpy-full in the act of installing my_new_package.
> AFAICS, this can
> only work as long as the set containing every variant can be ordered
> (in the conventional set ordering sense), and the dependency can be
> satisfied by the smallest one.
> 
Typically, the dependencies only depend on the smallest subset of what
they require (if they don't need lapack, they'd only depend on
python-numpy-core in your example), but yes, if there's an unsatisfiable
condition, then apt-get will raise an error and abort. In practice, this
system seems to work quite well, IMO.
Anyhow, here's the full Debian documentation:
http://www.debian.org/doc/debian-policy/ch-relationships.html

2010年1月2日 David Cournapeau <cou...@gm...>:
> 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 ?
Honestly, let's assume that there is currently no packaging system...
it would not be very far from the truth. I did it when I was young and
naive regarding Python. Actually I almost did it without having
writing any code in Python (approx. two months after earing about the
Python language for the first time) : it's an ugly collection of
AutoIt, NSIS and PHP scripts -- most of the tasks are automated like
updating the generated website pages and so on.
So I'm not proud at all, but it was easy and very quick to do as it
is, and it's still quite easy to maintain. But, it's not satisfying in
terms of code "purity" -- I've been wanting to rewrite all this in
Python for a year and a half but since the features are there, there
is no real motivation to do the work (in other words, Python(x,y)
users would not see the difference, at least at the beginning).
An other thing: Python(x,y) plugins are not built from source but from
existing binaries (it's a pity I know, but it was incredibly faster to
do this way). For example, eggs or distutils .exe may be converted in
Python(x,y) plugins directly (same internal directory structure).
So it may be different from the idea you had in mind (it's not like
EPD which is entirely generated from source, AFAIK).
> In the meantime, I will try to clean-up the code to have a first
> experimental release.
>
Ok, keep up the good work!
Cheers,
Pierre

On Sat, Jan 2, 2010 at 4:58 PM, Gael Varoquaux
<gae...@no...> wrote:
> 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:
I don't think virtual-packages entirely fix the issue. AFAIK, virtual
packages have two uses:
 - handle dependencies where several packages may resolve one
particular dependency in an equivalent way (one good example is
LAPACK: both liblapack and libatlas provides the lapack feature)
 - closer to this discussion, you can build several variants of the
same package, and each variant would resolve the dependency on a
virtual package handling the commonalities. For example, say we have
two numpy packages, one built with lapack (python-numpy-full), the
other without (python-numpy-core). What happens when a package foo
depends on numpy-full, but numpy-core is installed ? AFAICS, this can
only work as long as the set containing every variant can be ordered
(in the conventional set ordering sense), and the dependency can be
satisfied by the smallest one.
cheers,
David

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