matplotlib-devel Mailing List for matplotlib

Tested on Solaris8/Python 2.3.4, RHEL3/Python2.4,
MacOSX 10.3.9/Python2.4 - no problems.
Thanks for making the change!
Nadia
> 
> Committed. Please test. This REALLY cleans up the setup.py file. 
> Should hopefully address the building non-eggs with setuptools issue.
> 
> Thanks again,
> 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

Robert Kern wrote:
> The problem with this approach is that people using easy_install to grab sources
> and build an egg won't be able to see the extra information that is being put
> into setup_bdist_egg.py and might be crucial to specifying dependencies. I like
> Andrew's approach better, for mpl and ipython, too. I wish I'd thought of it myself.
OK: I'll leave it to you eggsperts to sort out the finer points of this 
problem. As long as mpl doesn't silently pull in setuptools anymore, I'm 
happy as a puppy.
Cheers,
f

Well, after the changes today the only setuptools modification to the
setup.py file is the addition of the "namespace_packages =3D
['matplotlib.toolkits']" for basemap support and eggs. So I think the
`python setup_bdist_egg.py` is a good idea. I'll add it barring any
objections (which I doubt there will be).
- Charlie
On 1/26/06, Fernando Perez <Fer...@co...> wrote:
> 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 bro=
ken
> (as it seems to be most of the time for me: I hate setuptools with a pass=
ion,
> for reasons too long to get into right now).
>
> Making sure that the mere _presence_ of setuptools in your path doesn't a=
ll 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, alon=
g the
> lines of
>
> http://projects.scipy.org/ipython/ipython/browser/ipython/trunk/setup_bdi=
st_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
>

Fernando Perez wrote:
> 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).
My understanding is that both solutions use essentially the same technique for
emulating package_data. The major difference is that the extension in ipython
allows you to specify some data to go wherever --install-data points and some
other data to go into the package itself. I don't think mpl has such a split.
And I don't think it should have one, either!
-- 
Robert Kern
rob...@gm...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

Fernando Perez wrote:
> 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
The problem with this approach is that people using easy_install to grab sources
and build an egg won't be able to see the extra information that is being put
into setup_bdist_egg.py and might be crucial to specifying dependencies. I like
Andrew's approach better, for mpl and ipython, too. I wish I'd thought of it myself.
-- 
Robert Kern
rob...@gm...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

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