[SciPy-dev] [Numpy-discussion] Thoughts on making it easier for numarray users to transition to scipy_core

Arnd Baecker arnd.baecker at web.de
Tue Dec 13 01:41:30 CST 2005

On Mon, 12 Dec 2005, Robert Kern wrote:

> Arnd Baecker wrote:
> > On Mon, 12 Dec 2005, Travis Oliphant wrote:
> >
> >>Robert Kern wrote:
> >>
> >>>Travis Oliphant wrote:
> >>>
> >>>>On a related note,  where should the Packages (like nd_image) from
> >>>>numarray go?  Should they all go into scipy core, full scipy, or be
> >>>>separately downloadable as scipy_core addons?
> [This bit got snipped. Me:]
> Let's work on making each subpackage in full scipy a "separately downloadable
> scipy_core addon."
> >>This is my preferred approach and I think we are almost there with the
> >>current scipy (minus a few inter-dependent addons).
> >
> > Does this also mean that a user will be able to  install
> >   - scipy core to one place
> >   - full scipy to some other place
> > and just add both placees to PYTHONPATH?
> >
> > This would be very helpful for parallel installations making
> Only if we require a recent setuptools to be installed.

I just had a look at http://peak.telecommunity.com/DevCenter/setuptools
They even have what they call `bootstrap module`, ez_setup.py,
which by inclusion
"will automatically download and install setuptools if the user is
building your package from source and doesn't have a suitable version
already installed."

(Personally, I am not a big fan of software "phoning" home/somewhere,
but during installation, one could just check if a sufficiently
new setuptools exists, and if not,  just
   print "please run `python ez_setup.py` before installation"
   print "to get a sufficiently new setuptools"
and stop.

> Neither scipy_core nor
> scipy would have to be built as eggs, but pkg_resources would have to be
> available. I think the .egg-info metadata would also have to be present.

That sounds really great to me!

> Of course, if we do that, then we can also use that metadata to collect
> docstrings and unit test locations in a robust way.

Sounds like another big benefit -
E.g. one could have routines from different sandboxes
floating around, or own code which will use the scipy machinery,
but is not (yet) in scipy.
This could make contributions easier and lead to many scipy-toolboxes!



P.S.: With  the following lines in `.pydistutils.cfg`
install_lib = ~/.PythonLibrary/Python$py_version_short/site-packages

a `python ez_setup.py` worked fine as non-root on a debian sarge
linux box with python 2.3.5.

More information about the Scipy-dev mailing list