[SciPy-dev] scipy / f2py / debian

eric jones eric at enthought.com
Sun Aug 25 22:09:41 CDT 2002


> On Sun, 25 Aug 2002, Steve M. Robbins wrote:
> 
> > On Sun, Aug 25, 2002 at 06:30:58AM -0500, Pearu wrote:
> >
> > > Yes, you are right. f2py and scipy_distutils are developed very
> closely,
> > > so usually there is no problem if either scipy or f2py installs
> > > scipy_distutils, just make sure that you have the latest
> scipy_distutils
> > > from scipy CVS. I also use symlink from scipy to f2py2e directory
> while
> > > working with the codes. However, if you really want to stop f2py
to
> > > re-installing scipy_distutils, then you must edit f2py2e/setup.py.
> >
> > This is fine when working with both sources from CVS, but how about
> > the binary packages of f2py and scipy?
> >
> > One of the other hats I wear is "Debian developer", and I'm
interested
> > in getting a package of scipy in Debian.  [And f2py, since scpiy
> > requires it to build.]  Joe Reinhardt has made some experimental
> > packages, but they have not yet been uploaded to Debian proper.
> >
> > It is possible to have the f2py and scipy packages both install
> > scipy_distutils, but this is a nuisance.  I would be worried that at
> > some point the packages' copies get out of sync, and that installing
> > "f2py" would cause "scipy" to stop working, or vice-versa.
> >
> > I can think of two ways to uncouple the two packages.  One is to
> > have f2py install/use the distutils under a different name, e.g.
> > f2py_distutils.
> 
> That way makes little sense since then scipy_distutils will be hardly
used
> in  the scipy building process and the required patch to f2py would be
> non-trivial.
> 
> > The other way is to split out scipy_distutils into
> > a seperately-installable package that would be a prerequisite for
> > both scipy and f2py.
> 
> That makes more sense. Both scipy and f2py setup.py scripts can be
easily
> patched to not install scipy_distutils and scipy_distutils can be
> installed as a separate package.

Packaging issues are always difficult to resolve.

The best solution is actually for scipy_distutils to be rolled into
Python's distutils.  That is what I would like to see happen, but I
don't think its inclusion is extremely.  We broached the subject once on
the distutils sig, and the only response besides mine and Pearu's was
from Paul Dubois saying it was a bad idea.  I disagree but don't have
the time to push this battle hard.  I think it would take quite a bit of
work (convincing and coding) to get it into the core.  If someone wants
to champion this issue, I'm all for it.

> 
> > I realise that either solution causes work for you, and that binary
> > packaging isn't your primary concern at the moment.  However, I
thought
> > I'd test the waters to see whether decoupling the packages is at all
> > feasible.  Perhaps there are other options that I'm overlooking.
> 
> Note that the binary package of scipy does not use scipy_distutils.
So,
> once scipy is built, it does not need scipy_distutils anymore.
> Therefore installing "f2py" with either older or newer scipy_distutils
> cannot affect "scipy" work. However, the other way is possible,
> especially when one installs scipy with older scipy_distutils.
> 
> Actually, now I don't see why scipy should install scipy_distutils.
> I would suggest removing scipy_distutils from the  separate_packages
list
> in scipy/setup.py to avoid possible conflicts.
> 
> There might be also a third way. Both scipy and f2py setup.py scripts
> can compare the versions of scipy_distutils they carry and what is
> installed already. If the installed scipy_distutils is older, only
then
> either of packages re-install scipy_distutils.
> Hmm, again, if one already has f2py installed but scipy installs the
> newer scipy_distutils then there is a possibility that f2py
installation
> will be broken. But not vice versa.
> So, my conclusion is that scipy should not install scipy_distutils.
> 
> Other thoughts?

I actually use scipy_distutils for quite a bit of my packaging needs
outside of scipy, even if the package doesn't have fortran code in it.
I don't want our users to have to install another package (other than
scipy) to install these "secondary" packages.  So, in most cases, I'd
like scipy to continue to install scipy_distutils.

On the Debian front, I am not well acquainted with Debian's packaging
process other than knowing that it is very good.  If scipy_distutils is
separated out, is it possible to have a package automatically install
its dependencies from some central repository? If so packaging
scipy_distutils separately in the binaries for this platform would make
sense.

I think the packaging process will evolve for scipy, and it is a balance
between keeping the installation simple and handling cases like this.  I
view scipy as a "standard library" for scientific computing analogous to
python's standard library.  As such, I tend toward the "install
everything together" end of the spectrum, but am stilling forming
opinions on the subject.  For now, though, I want scipy_distutils to be
installed by the scipy setup.py script.

eric




More information about the Scipy-dev mailing list