[Nipy-devel] Setup.py and platform specific shared objects
Sat Jan 15 09:43:15 CST 2011
On Fri, Jan 14, 2011 at 6:45 AM, Gael Varoquaux <
> On Thu, Jan 13, 2011 at 08:22:56PM +0000, Eleftherios Garyfallidis wrote:
> > My advice is: separate clearly several downloads
> > 1. The source package, that contains no binary (you can ship the
> > Cython-generated files to avoid the dependency on Cython).
> > Sorry, can you elaborate more your thoughts on this? You mean to ship
> > independently the compiled code? So, I suppose in that case someone
> > have to do first
> > easy_install dipy
> > and then download the 4 compiled shared objects for his platform and
> > them in the correct place?
> No. What I suggestion would rely on downloading a completely different
> tarball by platform. PyPI has support for this. For instance, if you look
> at the scikits.learn PyPI page,
> it has the following downloads:
> In other words, easy_install (or pip) will first try to download a binary
> package matching the target platform, and then, if it doesn't find it,
> the source tarball. These binary package are all built by using distutils
> command (bdist) on the corresponding platforms. Given that you need one
> binary package per version of Python, and per platform, you can see that
> there is quite a combinatorial explosion.
> And there are more problems hiding: for distutils, binary compatibility
> is defined by a platform name and a Python version. There might be other
> sources of binary incompatibility. Specificaly: the numpy version. As you
> know, recent numpy releases are binary incompatible with older ones.
> Under linux, the platform name is not detailed enough. I don't think
> that, with the current state of Python packaging, these issue can be
> resolved with pip or easy_install. If you want to provide binary
> packages, the best option is probably to do several compilations, each
> time in the right target environment, and provide them all on a download
> page with precise instruction on choosing which one is appropriate.
> > So you can do something like
> > easy_install dipy
> > cd dipy
> > python set_libs.py
> :). easy_install will not work like this: it downloads and installs the
> software in one step, so there is no directory in which you can cd to
> complete the installation.
> > 2. Binary packages, with the binary files. In this case, for
> > it is best to provide a '.exe' installer built with
> > That's the way we do it for the scikit.
> > Do you have any tutorials or any scripts on how to do this?
> No. I'd try Alexis's suggestion first. I would also read all I can on
> > For linux, the best way to ship binaries is problably to use
> > Anyone who could help with the RPMs?
> Not me, as I don't know enough for that. I don't provide binary package
> (and thus try to avoid having compiled code) because I find that dealing
> with all the different platforms is just too much work.
> OK I think I understand what you are suggesting and it is true that is a
lot of work to compile the project for every single os and python version.
And further more difficult for different versions. In summary we would need
this means 15 compilations which I don't have the time at the moment to
setup perhaps I can do on a next release after my course is over. One option
is to ask from Window users to install pythoxy or enthought distribution and
then do python setup.py install That should work just fine because they
provide mingw and cython.
For Debian users we can have a description of all the different apt-gets
which are needed and for MAC perhaps we can just make the eggs. I think
Matthew has already made some of them and I made a linux egg but only for
py2.6 64bit I don't have 32bit linux neither know how safe is to switch to
different python versions on the same system.
Good luck :)
> Nipy-devel mailing list
> Thanks for the feedback Gael. Saw your video on scikits.learn. Cool stuff!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nipy-devel