matplotlib-devel Mailing List for matplotlib (Page 2)

Andrew Straw wrote:
> I'm myself not 100% sure we want to use this patch, but I think perhaps
> it's better -- people who happen to have setuptools installed don't get
> setuptools-built packages unless they ask for them.

which is a big plus: recently I couldn't get matplotlib to install with a 
plain 'setup.py install' because setuptools was found in my path, but broken 
(as it seems to be most of the time for me: I hate setuptools with a passion, 
for reasons too long to get into right now).

Making sure that the mere _presence_ of setuptools in your path doesn't all of 
a sudden break all manner of things for matplotlib is a big plus.

You could always ship a little script specifically to build the egg, along the 
lines of

http://projects.scipy.org/ipython/ipython/browser/ipython/trunk/setup_bdist_egg.py

Normal builds would be uncontaminated by setuptools, and those who happen to 
like it can just call

python setup_bdist_egg.py

instead of

python setup.py bdist_egg


In the interest of robustness for matplotlib, I think that sandboxing 
setuptools a little more is a good idea.

Cheers,

f

Nadezhda Dencheva wrote:
> What's wrong with Pete Shinners's smart_istall_data?
> I am thinking of using it in all our packages, so
> if someone knows of any drawbacks I'd like to hear
> about this.
> 
> I've spent hours trying to construct a distutils hack that
> will force bdist_wininst to package data correctly and this
> one just works, (that's why I'm so impressed).

It seems you guys have found a solution already, but just in case it's of any 
use (now or later), you may want to glance at

http://projects.scipy.org/ipython/ipython/browser/ipython/trunk/setupext

This little snippet of code was contributed to ipython long ago, to assist 
with data packaging (compatible with python 2.2, including bdist_rpm and 
bdist_wininst).

Here's the setup.py that uses it:

http://projects.scipy.org/ipython/ipython/browser/ipython/trunk/setup.py

all you do is pass to setup the line

       cmdclass         = {'install_data': install_data_ext},

and the files listed as data_files get handled by it.

If it's of any use, feel free to grab it.

Cheers,

f

Charlie Moad wrote:

>On 1/26/06, Charlie Moad <cw...@gm...> wrote:
>  
>
>>On 1/26/06, Nadezhda Dencheva <den...@st...> wrote:
>>    
>>
>>>What's wrong with Pete Shinners's smart_istall_data?
>>>I am thinking of using it in all our packages, so
>>>if someone knows of any drawbacks I'd like to hear
>>>about this.
>>>      
>>>
>>Um wow, absolutely no problems as far as I can tell.  We don't even
>>have to shuffle around folders in cvs.  Thanks for forcing me to try
>>this! ;)
>>
>>After some more testing I will commit this simple fix.
>>    
>>
>
>Committed.  Please test.  This REALLY cleans up the setup.py file. 
>Should hopefully address the building non-eggs with setuptools issue.
>
>  
>
Charlie, it works for me. Here's an idea which will mean setuptools
isn't imported by setup.py, even for those who have setuptools installed
but don't want to use it. (I guess there might be some.)

The downside is that to use setuptools, you'd have to do some thing like:

python -c "import setuptools; execfile('setup.py')" bdist_egg
or
python -c "import setuptools; execfile('setup.py')" install

(I think "easy_install ." is also supposed to work, but it looks I've
got a few poorly-behaving modules installed...)

I'm myself not 100% sure we want to use this patch, but I think perhaps
it's better -- people who happen to have setuptools installed don't get
setuptools-built packages unless they ask for them.

Thanks for your work on this,
Andrew

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
    Charlie> Committed.  Please test.  This REALLY cleans up the
    Charlie> setup.py file.  Should hopefully address the building
    Charlie> non-eggs with setuptools issue.

I got clean installs and runs of backend_driver on python2.4/linux and
python2.3/solaris so it looks good so far.  I can test on my powerbook
tonight.

JDH

On 1/26/06, Charlie Moad <cw...@gm...> wrote:
> On 1/26/06, Nadezhda Dencheva <den...@st...> wrote:
> > What's wrong with Pete Shinners's smart_istall_data?
> > I am thinking of using it in all our packages, so
> > if someone knows of any drawbacks I'd like to hear
> > about this.
>
> Um wow, absolutely no problems as far as I can tell.  We don't even
> have to shuffle around folders in cvs.  Thanks for forcing me to try
> this! ;)
>
> After some more testing I will commit this simple fix.

Committed.  Please test.  This REALLY cleans up the setup.py file.=20
Should hopefully address the building non-eggs with setuptools issue.

Thanks again,
     Charlie

On 1/26/06, Nadezhda Dencheva <den...@st...> wrote:
> What's wrong with Pete Shinners's smart_istall_data?
> I am thinking of using it in all our packages, so
> if someone knows of any drawbacks I'd like to hear
> about this.

Um wow, absolutely no problems as far as I can tell.  We don't even
have to shuffle around folders in cvs.  Thanks for forcing me to try
this! ;)

After some more testing I will commit this simple fix.

Thanks,
     Charlie

What's wrong with Pete Shinners's smart_istall_data?
I am thinking of using it in all our packages, so
if someone knows of any drawbacks I'd like to hear
about this.

I've spent hours trying to construct a distutils hack that
will force bdist_wininst to package data correctly and this
one just works, (that's why I'm so impressed).

Nadia

Charlie Moad wrote:
>>Isn't package_data available only in python 2.4?
> 
> 
> Doh!  That's probably a good reason not to implement this is cvs yet.  : (
> I guess I am at a loss then, and what we have now will probably have
> to do.  Maybe when setuptools becomes more accepted we can force it as
> default with the "import ez_setup; ez_setup.use_setuptools()" line up
> top.  I imagine package_data works with python2.3 and setuptools.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

> Isn't package_data available only in python 2.4?

Doh!  That's probably a good reason not to implement this is cvs yet.  : (
I guess I am at a loss then, and what we have now will probably have
to do.  Maybe when setuptools becomes more accepted we can force it as
default with the "import ez_setup; ez_setup.use_setuptools()" line up
top.  I imagine package_data works with python2.3 and setuptools.

Isn't package_data available only in python 2.4?

Robert, thanks for pointing to Pete Shinners' s code
for handling data. As far as I can tell it covers all cases
(even bdist_wininst!).

I was going to suggest using it.

Nadia Dencheva

Charlie Moad wrote:
> Hey all (esp John and Robert),
> 
>      So I got sick of telling people package_data was the right
> approach and finally just did it.  Code wise it required very little
> change.  It did require moving the data files into the matplotlib
> module though, so look in lib/matplotlib/mpl-data.  Below is a link to
> the sdist from the cvs-source I modified.  Please look at it and try
> it out.  You'll notice that all the datapath logic has been removed
> from the setup.py file.  All that is done is specifying the
> package_data.
>      If you guys have no problems with this I will implement it in
> cvs.  Obviously we would have to request that the current font and
> images directories be removed from cvs.  Hopefully this correct
> approach will save us from headaches down the road.
> 
> http://euclid.uits.iupui.edu/~cmoad/matplotlib-pkgdata-0.86.2.tar.gz
> 
> - Charlie
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hey all (esp John and Robert),

     So I got sick of telling people package_data was the right
approach and finally just did it.  Code wise it required very little
change.  It did require moving the data files into the matplotlib
module though, so look in lib/matplotlib/mpl-data.  Below is a link to
the sdist from the cvs-source I modified.  Please look at it and try
it out.  You'll notice that all the datapath logic has been removed
from the setup.py file.  All that is done is specifying the
package_data.
     If you guys have no problems with this I will implement it in
cvs.  Obviously we would have to request that the current font and
images directories be removed from cvs.  Hopefully this correct
approach will save us from headaches down the road.

http://euclid.uits.iupui.edu/~cmoad/matplotlib-pkgdata-0.86.2.tar.gz

- Charlie

Seems my attachment might not have gone through.  Trying again.

Hello,

Attached is a patch against CVS to allow one to change the color of  
the tick markers through the rc system.  I use it to increase the  
visibility of (normally black) ticks when displaying a dark image  
with imshow().

Best,
Mike

Ted Drain wrote:
> Maybe one of you guys could refresh my memory.  What is the calling 
> sequence we're going for?

My original message was this:

============================================================================
In [1]: gcf().set_figsize_inches((8,8),forward=True)
---------------------------------------------------------------------------
exceptions.TypeError                                 Traceback (most recent
call last)

/home/fperez/code/python/pylab/arrows/<ipython console>

/usr/lib/python2.3/site-packages/matplotlib/figure.py in
set_figsize_inches(self, *args, **kwargs)
      266             canvasw = w*dpival
      267             canvash = h*dpival
--> 268             self.canvas.resize(int(canvasw), int(canvash))
      269
      270     def get_size_inches(self):

TypeError: resize() takes exactly 2 arguments (3 given)


A quick look at the backends code shows this:

      def resize(self, event):
          width, height = event.width, event.height
          self.toolbar.configure(width=width) # , height=height)

So quite obviously, this doesn't work: it's expecting an event object, and a
pair of numbers is being passed.

I'm not sure what the proper fix should be here, I don't really know the code
flow well enough.

I should also note that the gcf().set_figsize_inches((8,8),forward=True) seems
to produce a different on-screen result per backend (in some it doesn't do
anything, in Qt it stretches the figure only horizontally, ...)  That code
seems to be pretty much broken.

I noticed that figure(figsize=(8,8)) seems to work fine, but I'm not sure how
to programmatically resize an existing figure, given the above problems.
============================================================================

Beyond this, I'll leave it to the backend experts as to what the right choices 
should be.  I just noted that shipping a feature _known_ to break on all but 
one backend doesn't sound like the best approach :)

Cheers,

f

Charlie Moad wrote:

> I left the check for this env variable there for this reason.  Just in
> case someone wants to put the data somewhere else on the system.  It
> doesn't support a list of directories now, but wouldn't you presume
> the user who sets it knows where the data is?  Privileges should not
> be an issue at all now since the data is embedded in the module.

Sure, but he may be putting data in multiple places (fonts in one directory,
colormaps in another, basemap data in a third, etc.). Or only providing a few
new pieces of data, not the complete suite of data.

And once we use a path-based approach, it would be easy to keep fonts and other
data in separate directories inside the package. You simply append both
directories to the end of MATPLOTLIBDATAPATH. AFAICT, that's the only objection
against moving the data into the lib/matplotlib/mpl-data/ in the source
distribution.

> I still think the best approach is going to be to specify the mpldata
> as package_data, like it is, instead of data_files.  Then all the
> logic in the setup file goes away.  I tried this, but distutils would
> not respect "../fonts" type directories.  We would actually have to
> move the data files into the mpl module.

Yes, I agree with you. Believe me, I'm not arguing against installing data in
the package itself.

> Matplotlib is a python plugin, not an application.  I can't think of
> any other python modules that dump their data files around the system
> during installation. 

Oh, there are plenty, but they all suck for doing so. Unless if they are
following a particular standard, like Gnome or KDE applications.

-- 
Robert Kern
rob...@gm...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

On 1/25/06, Robert Kern <rob...@gm...> wrote:
> Charlie Moad wrote:
> > Short explanation:
> >      Use --prefix instead
> >
> > Long explanation:
> >      Without explicitly moving around files in cvs and declaring the
> > mpl data as package_data, it is pretty hard to be 100% compliant.  The
> > code you put below is basically how distutils now determines where to
> > stick data_files, and that is why I used it as a guide too faking it.
> > --home is unix specific I think, and I don't know that it gives you
> > any power over --prefix.  --install-data is useless now since the data
> > is embedded into the matplotlib module itself.
>
> There is another problem with the current approach. The current setup.py =
assumes
> that if you have an egg-capable setuptools that you are building an egg a=
nd so
> sets the data path for that. However, that's not always the case. For exa=
mple,
> the --single-version-externally-managed option should install matplotlib =
and
> company as regular Python packages into site-packages (or wherever) with =
a
> .egg-info/ directory alongside. This is how Debian (and presumably other
> distros) is going to install eggified packages. However, the choice for t=
he data
> path ends up being incorrect.

I have ran into this as well, and it is just coming from the game of
trying to make the setup file work with distutils and setuptools.

> I think a general rule might be to say that the innards of distutils are =
usually
> a bad example for *using* distutils. It makes a lot of assumptions inside=
, and
> the current mechanism in mpl's setup.py is fairly fragile. distutils is a=
 piece
> of junk, and really, really violates the "There should be one-- and prefe=
rably
> only one --obvious way to do it," principle everywhere it possibly can, i=
t seems.
>
> The most robust approach seems to be this:
>
>   http://wiki.python.org/moin/DistutilsInstallDataScattered
>
> >      I think I wrote a little a while back justifying the move, but
> > I'll restate.  If you look at older versions of the
> > matplotlib._get_data_path() method, it was becoming a huge collection
> > of special cases.  Those cases are still in cvs, but commented out.
> > It had the approach of try everything until I find the data.  Now you
> > could acutally write this method in one line, "return
> > os.sep.join([os.path.dirname(__file__), 'mpl-data'])".  However it
> > does a little more by still checking the MATPLOTLIBDATA env variable
> > first and verifying that the embedded mpl-data folder actually exists.
>
> Have we ever considered moving to a path-based solution? For example, one=
 would
> set MATPLOTLIBDATAPATH to be a list of directories. When something inside
> matplotlib needs data, it will go through the list of directories looking=
 for
> the file, and finally checking os.path.join([os.path.dirname(__file__),
> 'mpl-data']) if the file is not on the path. This would enable users with=
out
> privileges to manipulate site-packages or /usr/local/share to make replac=
ements
> or additions.

I left the check for this env variable there for this reason.  Just in
case someone wants to put the data somewhere else on the system.  It
doesn't support a list of directories now, but wouldn't you presume
the user who sets it knows where the data is?  Privileges should not
be an issue at all now since the data is embedded in the module.

I still think the best approach is going to be to specify the mpldata
as package_data, like it is, instead of data_files.  Then all the
logic in the setup file goes away.  I tried this, but distutils would
not respect "../fonts" type directories.  We would actually have to
move the data files into the mpl module.

Matplotlib is a python plugin, not an application.  I can't think of
any other python modules that dump their data files around the system
during installation.  I have seen many projects though with
glade/png/etc. files embedded into the module as package_data and they
avoid all these issues mentioned above.

Charlie Moad wrote:
> Short explanation:
>      Use --prefix instead
> 
> Long explanation:
>      Without explicitly moving around files in cvs and declaring the
> mpl data as package_data, it is pretty hard to be 100% compliant.  The
> code you put below is basically how distutils now determines where to
> stick data_files, and that is why I used it as a guide too faking it. 
> --home is unix specific I think, and I don't know that it gives you
> any power over --prefix.  --install-data is useless now since the data
> is embedded into the matplotlib module itself.

There is another problem with the current approach. The current setup.py assumes
that if you have an egg-capable setuptools that you are building an egg and so
sets the data path for that. However, that's not always the case. For example,
the --single-version-externally-managed option should install matplotlib and
company as regular Python packages into site-packages (or wherever) with a
.egg-info/ directory alongside. This is how Debian (and presumably other
distros) is going to install eggified packages. However, the choice for the data
path ends up being incorrect.

I think a general rule might be to say that the innards of distutils are usually
a bad example for *using* distutils. It makes a lot of assumptions inside, and
the current mechanism in mpl's setup.py is fairly fragile. distutils is a piece
of junk, and really, really violates the "There should be one-- and preferably
only one --obvious way to do it," principle everywhere it possibly can, it seems.

The most robust approach seems to be this:

  http://wiki.python.org/moin/DistutilsInstallDataScattered

>      I think I wrote a little a while back justifying the move, but
> I'll restate.  If you look at older versions of the
> matplotlib._get_data_path() method, it was becoming a huge collection
> of special cases.  Those cases are still in cvs, but commented out. 
> It had the approach of try everything until I find the data.  Now you
> could acutally write this method in one line, "return
> os.sep.join([os.path.dirname(__file__), 'mpl-data'])".  However it
> does a little more by still checking the MATPLOTLIBDATA env variable
> first and verifying that the embedded mpl-data folder actually exists.

Have we ever considered moving to a path-based solution? For example, one would
set MATPLOTLIBDATAPATH to be a list of directories. When something inside
matplotlib needs data, it will go through the list of directories looking for
the file, and finally checking os.path.join([os.path.dirname(__file__),
'mpl-data']) if the file is not on the path. This would enable users without
privileges to manipulate site-packages or /usr/local/share to make replacements
or additions.

-- 
Robert Kern
rob...@gm...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

On Jan 25, 2006, at 11:51 AM, Charlie Moad wrote:

> Short explanation:
>      Use --prefix instead

Hmm, I don't want to use --prefix.

I understand the reasoning behind this change but I think it misses one
important case - installations under a user specified directory=20
(without getting the
unnecessary tree structure from '--home' and ''--prefix'),
For example, to install matplotlib under /home/users/matpltolib in the=20=

past
I would do

python setup.py install --install-lib=3D/home/user=20
--install-data=3D/home/user/matplotlib

This, I think,  covers two important cases:
- easy support for multiple versions on the system
- installation in a user directory (not having write permissions in=20
site-packages)

Of course this can be done (in an ugly way) with --prefix.
I think you and I need the same kind of installation - data files=20
bundled with
matplotlib, except that I don't want to install them in site-packages=20
and this is
what's missing from the setup file now.

Am I missing something?

Nadia

> Long explanation:
>      Without explicitly moving around files in cvs and declaring the
> mpl data as package_data, it is pretty hard to be 100% compliant.  The
> code you put below is basically how distutils now determines where to
> stick data_files, and that is why I used it as a guide too faking it.
> --home is unix specific I think, and I don't know that it gives you
> any power over --prefix.  --install-data is useless now since the data
> is embedded into the matplotlib module itself.
>      I think I wrote a little a while back justifying the move, but
> I'll restate.  If you look at older versions of the
> matplotlib._get_data_path() method, it was becoming a huge collection
> of special cases.  Those cases are still in cvs, but commented out.
> It had the approach of try everything until I find the data.  Now you
> could acutally write this method in one line, "return
> os.sep.join([os.path.dirname(__file__), 'mpl-data'])".  However it
> does a little more by still checking the MATPLOTLIBDATA env variable
> first and verifying that the embedded mpl-data folder actually exists.
>      Another strong reason for the move is it makes matplotlib a lot
> more embeddable.  I personally have some plugins I have developed for
> applications that ship with their own python, and it is much easier to
> just drop matplotlib into on place, and not have to worry about
> installing data files outside the scope of the application.  It also
> allows for multiple versions/instances of matplotlib to live on one
> machine, where as before they would be forced to use a single version
> of the dataset unless special care was taken to prevent that.
>
> - Charlie
>
> On 1/25/06, Nadezhda Dencheva <den...@st...> wrote:
>> Hello,
>>
>> I somehow missed all the action between matplotlib 0.84 and 0.86.2.
>> Trying to install v0.86.2 I find data files are not installed=20
>> correctly
>> in all cases. Specifically support for '--home=3D' and =
'--install-data'=20
>> is
>> broken. (We use --install-data for our installations.)
>>
>> I know this is a very tricky issue (in fact if someone can tell me
>> how to get this done correctly for bdist_wininst, I'll be very=20
>> gratefull)
>> but here's a suggestion which worked for me. I am copying the =
relevant
>> part from setup.py and hope someone has a better solution.
>>
>> Thanks,
>> Nadia Dencheva
>>
>>
>> if has_setuptools: # EGG's make it simple
>>      datapath =3D os.path.curdir
>>      datapath =3D os.sep.join([datapath, 'matplotlib', 'mpl-data']) #=20=

>> This is where mpl data
>> will be installed
>> # logic from distutils.command.install.finalize_options
>> elif os.name =3D=3D 'posix':
>>      py_version_short =3D sys.version[0:3]
>>      #datapath =3D INSTALL_SCHEMES['unix_prefix']['platlib']
>>      #datapath =3D datapath.replace('$platbase/',=20
>> '').replace('$py_version_short',
>> py_version_short)
>>      #datapath =3D os.sep.join(['mpl-data']) # This is where mpl data=20=

>> will be installed
>>      args =3D sys.argv
>>      for a in args:
>>          if a.startswith('--home=3D'):
>>              dir =3D os.path.abspath(a.split('=3D')[1])
>>              datapath =3D os.path.join(dir, 'lib', 'python',=20
>> 'matplotlib', 'mpl-data')
>>          elif a.startswith('--prefix=3D'):
>>              dir =3D os.path.abspath(a.split('=3D')[1])
>>              pythonver =3D 'python'+py_version_short
>>              datapath =3D os.path.join(dir, 'lib', pythonver,=20
>> 'site-packages', 'matplotlib',
>> 'mpl-data')
>>          elif a.startswith('--install-data=3D'):
>>              dir =3D os.path.abspath(a.split('=3D')[1])
>>              datapath =3D os.path.join(dir, 'mpl-data')
>>          else:
>>              pythonlib =3D=20
>> distutils.sysconfig.get_python_lib(plat_specific=3D1)
>>              datapath =3D os.path.join(pythonlib, 'matplotlib',=20
>> 'mpl-data')
>> else:
>>      datapath =3D =
INSTALL_SCHEMES[os.name]['platlib'].replace('$base/',=20
>> '')
>>      datapath =3D os.sep.join([datapath, 'matplotlib', 'mpl-data']) #=20=

>> This is where mpl data
>> will be installed
>>
>> Charlie Moad wrote:
>>> Alright, I'll give it a shot and let you know.
>>>
>>> On 12/7/05, John Hunter <jdh...@ac...> wrote:
>>>
>>>>>>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>>>>
>>>>    Charlie> Would it be considered cleaner to embed the mpl data=20
>>>> into
>>>>    Charlie> the matplotlib module?  This would make it easier to
>>>>    Charlie> clean a mpl install.  The data path could be expressed
>>>>    Charlie> fairly easily too, as a one-liner:
>>>>
>>>>    Charlie> os.sep.join([os.path.split(matplotlib.__file__)[0],
>>>>    Charlie> 'matplotlib-data'])
>>>>
>>>> Yes, if you can engineer in a way that works with setup w/ and w/o =
a
>>>> --prefix arg it would be preferable, in my view.
>>>>
>>>> JDH
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc. Do you grep through=20=

>>> log files
>>> for problems?  Stop!  Download the new AJAX search engine that makes
>>> searching your log files as easy as surfing the  web.  DOWNLOAD=20
>>> SPLUNK!
>>> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>

Short explanation:
     Use --prefix instead

Long explanation:
     Without explicitly moving around files in cvs and declaring the
mpl data as package_data, it is pretty hard to be 100% compliant.  The
code you put below is basically how distutils now determines where to
stick data_files, and that is why I used it as a guide too faking it.=20
--home is unix specific I think, and I don't know that it gives you
any power over --prefix.  --install-data is useless now since the data
is embedded into the matplotlib module itself.
     I think I wrote a little a while back justifying the move, but
I'll restate.  If you look at older versions of the
matplotlib._get_data_path() method, it was becoming a huge collection
of special cases.  Those cases are still in cvs, but commented out.=20
It had the approach of try everything until I find the data.  Now you
could acutally write this method in one line, "return
os.sep.join([os.path.dirname(__file__), 'mpl-data'])".  However it
does a little more by still checking the MATPLOTLIBDATA env variable
first and verifying that the embedded mpl-data folder actually exists.
     Another strong reason for the move is it makes matplotlib a lot
more embeddable.  I personally have some plugins I have developed for
applications that ship with their own python, and it is much easier to
just drop matplotlib into on place, and not have to worry about
installing data files outside the scope of the application.  It also
allows for multiple versions/instances of matplotlib to live on one
machine, where as before they would be forced to use a single version
of the dataset unless special care was taken to prevent that.

- Charlie

On 1/25/06, Nadezhda Dencheva <den...@st...> wrote:
> Hello,
>
> I somehow missed all the action between matplotlib 0.84 and 0.86.2.
> Trying to install v0.86.2 I find data files are not installed correctly
> in all cases. Specifically support for '--home=3D' and '--install-data' i=
s
> broken. (We use --install-data for our installations.)
>
> I know this is a very tricky issue (in fact if someone can tell me
> how to get this done correctly for bdist_wininst, I'll be very gratefull)
> but here's a suggestion which worked for me. I am copying the relevant
> part from setup.py and hope someone has a better solution.
>
> Thanks,
> Nadia Dencheva
>
>
> if has_setuptools: # EGG's make it simple
>      datapath =3D os.path.curdir
>      datapath =3D os.sep.join([datapath, 'matplotlib', 'mpl-data']) # Thi=
s is where mpl data
> will be installed
> # logic from distutils.command.install.finalize_options
> elif os.name =3D=3D 'posix':
>      py_version_short =3D sys.version[0:3]
>      #datapath =3D INSTALL_SCHEMES['unix_prefix']['platlib']
>      #datapath =3D datapath.replace('$platbase/', '').replace('$py_versio=
n_short',
> py_version_short)
>      #datapath =3D os.sep.join(['mpl-data']) # This is where mpl data wil=
l be installed
>      args =3D sys.argv
>      for a in args:
>          if a.startswith('--home=3D'):
>              dir =3D os.path.abspath(a.split('=3D')[1])
>              datapath =3D os.path.join(dir, 'lib', 'python', 'matplotlib'=
, 'mpl-data')
>          elif a.startswith('--prefix=3D'):
>              dir =3D os.path.abspath(a.split('=3D')[1])
>              pythonver =3D 'python'+py_version_short
>              datapath =3D os.path.join(dir, 'lib', pythonver, 'site-packa=
ges', 'matplotlib',
> 'mpl-data')
>          elif a.startswith('--install-data=3D'):
>              dir =3D os.path.abspath(a.split('=3D')[1])
>              datapath =3D os.path.join(dir, 'mpl-data')
>          else:
>              pythonlib =3D distutils.sysconfig.get_python_lib(plat_specif=
ic=3D1)
>              datapath =3D os.path.join(pythonlib, 'matplotlib', 'mpl-data=
')
> else:
>      datapath =3D INSTALL_SCHEMES[os.name]['platlib'].replace('$base/', '=
')
>      datapath =3D os.sep.join([datapath, 'matplotlib', 'mpl-data']) # Thi=
s is where mpl data
> will be installed
>
> Charlie Moad wrote:
> > Alright, I'll give it a shot and let you know.
> >
> > On 12/7/05, John Hunter <jdh...@ac...> wrote:
> >
> >>>>>>>"Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
> >>
> >>    Charlie> Would it be considered cleaner to embed the mpl data into
> >>    Charlie> the matplotlib module?  This would make it easier to
> >>    Charlie> clean a mpl install.  The data path could be expressed
> >>    Charlie> fairly easily too, as a one-liner:
> >>
> >>    Charlie> os.sep.join([os.path.split(matplotlib.__file__)[0],
> >>    Charlie> 'matplotlib-data'])
> >>
> >>Yes, if you can engineer in a way that works with setup w/ and w/o a
> >>--prefix arg it would be preferable, in my view.
> >>
> >>JDH
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Maybe one of you guys could refresh my memory.  What is the calling 
sequence we're going for?

Ted

At 09:58 AM 1/23/2006, Fernando Perez wrote:
>Ted Drain wrote:
>>John & Fernando,
>>I think the basic problem can be solved in a number of ways.  Normally a 
>>GUI widget will have an initial size and when it is placed in a window, 
>>the window will layout around it (or to it's own size).  However, once 
>>the window is drawn, changing the size of one or more widget that it 
>>contains doesn't mean you're changing the size of the window.
>>Here's some ideas for how to fix this:
>
>Thanks for the feedback, Ted.  I hope one of your suggestions can be 
>implemented (2 sounds very reasonable). If not, at least I think the 
>'forward' option should then just be removed.  There's no point in 
>exposing a feature known to crash all but ONE backend, I think.
>
>Regards,
>
>f

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

Hello,

I somehow missed all the action between matplotlib 0.84 and 0.86.2.
Trying to install v0.86.2 I find data files are not installed correctly
in all cases. Specifically support for '--home=' and '--install-data' is
broken. (We use --install-data for our installations.)

I know this is a very tricky issue (in fact if someone can tell me
how to get this done correctly for bdist_wininst, I'll be very gratefull)
but here's a suggestion which worked for me. I am copying the relevant
part from setup.py and hope someone has a better solution.

Thanks,
Nadia Dencheva


if has_setuptools: # EGG's make it simple
     datapath = os.path.curdir
     datapath = os.sep.join([datapath, 'matplotlib', 'mpl-data']) # This is where mpl data 
will be installed
# logic from distutils.command.install.finalize_options
elif os.name == 'posix':
     py_version_short = sys.version[0:3]
     #datapath = INSTALL_SCHEMES['unix_prefix']['platlib']
     #datapath = datapath.replace('$platbase/', '').replace('$py_version_short', 
py_version_short)
     #datapath = os.sep.join(['mpl-data']) # This is where mpl data will be installed
     args = sys.argv
     for a in args:
         if a.startswith('--home='):
             dir = os.path.abspath(a.split('=')[1])
             datapath = os.path.join(dir, 'lib', 'python', 'matplotlib', 'mpl-data')
         elif a.startswith('--prefix='):
             dir = os.path.abspath(a.split('=')[1])
             pythonver = 'python'+py_version_short
             datapath = os.path.join(dir, 'lib', pythonver, 'site-packages', 'matplotlib', 
'mpl-data')
         elif a.startswith('--install-data='):
             dir = os.path.abspath(a.split('=')[1])
             datapath = os.path.join(dir, 'mpl-data')
         else:
             pythonlib = distutils.sysconfig.get_python_lib(plat_specific=1)
             datapath = os.path.join(pythonlib, 'matplotlib', 'mpl-data')
else:
     datapath = INSTALL_SCHEMES[os.name]['platlib'].replace('$base/', '')
     datapath = os.sep.join([datapath, 'matplotlib', 'mpl-data']) # This is where mpl data 
will be installed

Charlie Moad wrote:
> Alright, I'll give it a shot and let you know.
> 
> On 12/7/05, John Hunter <jdh...@ac...> wrote:
> 
>>>>>>>"Charlie" == Charlie Moad <cw...@gm...> writes:
>>
>>    Charlie> Would it be considered cleaner to embed the mpl data into
>>    Charlie> the matplotlib module?  This would make it easier to
>>    Charlie> clean a mpl install.  The data path could be expressed
>>    Charlie> fairly easily too, as a one-liner:
>>
>>    Charlie> os.sep.join([os.path.split(matplotlib.__file__)[0],
>>    Charlie> 'matplotlib-data'])
>>
>>Yes, if you can engineer in a way that works with setup w/ and w/o a
>>--prefix arg it would be preferable, in my view.
>>
>>JDH
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
    Darren> How does matplotlib render glyphs, does it use freetype?
    Darren> Would matplotlib be able to render tex's fonts with the
    Darren> existing codebase, or would I have to delve into metafont?

Yep, it uses freetype and no, we don't have any facility to render tex
fonts.  I think the dvi parsing project would be a very nice addition,
but not a trivial task.  The tex file formats are pretty arcane: Knuth
is fond of using bytecode in his data files, so you would have to
write a bytecode engine.  Robert Kern did this on a rainy afternoon
for the tfm files, so you could use that as an example

  http://sourceforge.net/mailarchive/message.php?msg_id=9894596

JDH

On Monday 23 January 2006 18:27, Robert Kern wrote:
> Darren Dale wrote:
> > I would like to ask for some advice from those out there who have
> > experience dealing with fonts and text layout.
> >
> > At the end of this message is the output of dvitype, which translates a
> > dvi file (in this case a file typesetting "0.8" in ptmr7t fonts) into
> > human readable output. I have considered writing a dvi parser for mpl,
> > intending to extract the information necessary to render text with mpl's
> > existing font and text support. There is some more information at
> > http://en.wikipedia.org/wiki/DVI_(TeX) and
> > http://www.math.umd.edu/~asnowden/comp-cont/dvi.html#setchar.
> >
> > Is this worth pursuing? If I could make it work, mpl's only external
> > dependency would be TeX/LaTeX, even dvipng would not be required.
>
> Quite probably. dvitype is new to me. Doing a DVI interpreter for mpl and
> Chaco has been on my list of things to look at for some time. The things
> stopping me (besides the density of the DVI standard) was that all of the
> readable code I found for interpreting DVI files has been GPLed.
>
> You will need to access the parameters defined in the TeX Font Metric
> files, I think. I recommend using tftopl(1) to convert them to a parseable
> form.

How does matplotlib render glyphs, does it use freetype? Would matplotlib be 
able to render tex's fonts with the existing codebase, or would I have to 
delve into metafont?

Hello,

My problem is the following : I would like to create an image using the 
matplolib facilities and then insert this image
in a <IMG SRC="*data*:*image*/???;base64 *.../> *element.
Then using Gecko (mozilla) and python + xpcom, I would try to interact 
with this image (zoom ...).

In order to succeed I feel I have to understand how a back-end is written.

It seems I have to start with the Figure class.
But then I can't find the image format, the way to return binary data or 
perhaps base64 data.
I don't want to save the figure in a file et then read it with <IMG 
SRC="theFile.png"/>.
The speed would be very low.

What is the process  to add a new back-end ?

I wish the encode/decode base64 wil not take too much time for keeping 
the dynamism of gtk back-end (for instance).
What do you think about that ?

Thanks a lot,

Cyril.

I have a suggestion for a feature in the 'resize window' discussion.

We really need some kind of callback when a window is resized manually in
interactive mode. That is, when somebody points his mouse to the corner of =
a
window and drags it to a bigger size. When this happens, and the plot in th=
e
window is supposed to be drawn to scale (so that circles look like circles)=
,
the size of the plot needs to be managed. That is not difficult to do, as
long as their is a signal given that the window was resized.

Thanks,

Mark

Hi Darren,

It's reasonable to be concerned about having two files necessary to
make one plot.  The gnuplot pslatex output doesn't do this: it writes
one output file that is essentially a latex "picture" environment
which includes an encapsulated postscript program for the "graphics
part" with a \special command, and uses \put(x,y){\makebox(0,0){TEXT}
for all the text.  Since latex has a preferred orientation for text
flow, each piece of rotated text is handled with another \special
command.    BTW, I was mistaken earlier when I said that axes were
drawn in latex with gnuplot's pslatex terminal -- they are included in
the postscript, and only text for axis labels and other text is added
in with latex.  So I think that emulating this solution would not be
too hard.

The output latex files do not render a figure by themselves, as they
are intended to be used in-place in documents and latex insists on
exactly one \begin{document} / \end{document} pair.   But it's trivial
to have a boilerplate outer latex file:

  \documentclass[11pt]{article}
  \usepackage{color,....}
  \pagestyle{empty}
  \begin{document}\begin{figure}{\input{fig.pstex}}\end{figure}\end{documen=
t}

for generating individual graphs, and then doing standard latex / dvips.

I am not necessarily advocating this as "the right way", but offer it
as a suggestion. I've made figures like this for many years.  OK, I
admit that I still make many figures for papers and talks this way, as
I know gnuplot, have scripts I've used for years, and there are some
things I can do more easily in gnuplot/latex than mpl.

Advantages of this approach are that a) the latex is not interpreted
by gnuplot, but handed off to latex (any valid latex can be used),=20
and b) the output latex/postscript is easily hackable.  The latex
parts (say, the labels) can be easily changed. Colors and linestyles
of the traces can also be changed simply by editng the postscript.  Of
course, "Oh, just hack the postscript" is not what mpl should aspire
too, but it's nice to know it's there when you need it.

A sample gnuplot script and output pslatex are at
    http://cars9.uchicago.edu/~newville/Python/MPlot/gnuplot-pslatex/

I also put a python script gp2ps (which requires Gnuplot.py) I use to
turn gnuplot command files with latex labels into eps (using dvips)
and png (using ImageMagick's convert) outputs.  Feel free to use this
any way you want, or ignore it. Again, I'm not saying that this is
"doing tex support the right way", but it might beat the headache of
relying on version-specific features of gs.

Cheers,

--Matt