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
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
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.
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
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
···
On 1/26/06, Nadezhda Dencheva <dencheva@...31...> 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.
Committed. Please test. This REALLY cleans up the setup.py file.
Should hopefully address the building non-eggs with setuptools issue.
Thanks again,
Charlie
···
On 1/26/06, Charlie Moad <cwmoad@...149...> wrote:
On 1/26/06, Nadezhda Dencheva <dencheva@...31...> 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.
Charlie Moad 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
setup-setuptoolsless.patch (1.38 KB)
···
On 1/26/06, Charlie Moad <cwmoad@...149...> wrote:
On 1/26/06, Nadezhda Dencheva <dencheva@...31...> 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).
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
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
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
robert.kern@...149...
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
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
robert.kern@...149...
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
Well, after the changes today the only setuptools modification to the
setup.py file is the addition of the "namespace_packages =
['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 <Fernando.Perez@...76...> 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
In the interest of robustness for matplotlib, I think that sandboxing
setuptools a little more is a good idea.
Cheers,
f
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
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options