[SciPy-dev] Accessible SciPy (ASP) project

[Fernando Perez]

Prabhu Ramachandran wrote:
>>>>>>"RK" == Robert Kern <rkern at ucsd.edu> writes:
> 
> 
>     RK> IPython seems to be orthogonal to scipy. I'd be -1 on making
>     RK> IPython depend on scipy or scipy_core. IPython's potential
>     RK> audience is much wider than scipy's. Looking the other way, I
> 
> With all due respect to Fernando, I agree.

No need to apologize, since I also agree :)  I think the issue is one of 
'advertising' ipython as the default environment for new scientific users, not 
so much one of software architecture.  And this goal can be achieved simply 
via packaging and documentation, without the need to make either tool a 
dependency for the other (scipy & ipython).

>     RK> don't think scipy would benefit much from having IPython as
>     RK> part of it. Perhaps when IPython gets rewritten to be a more
>     RK> flexible library for building interactive environments, then
>     RK> it would make some sense to bundle IPython into scipy.
> 
> Actually, that only makes the case stronger for it to be separate from
> scipy.  I think all that needs to be done is for IPython to be bundled
> along with Enthon.  Installing IPython on non-MS platforms is a
> breeze.  Perhaps a yum archive or something for those who don't want
> to mess with source tarballs or GNU/stow[1].  

Now that ipython works really well under Windows, I do think it would be nice 
if Enthon included it by default (since it already, I think, provides ctypes 
and the win32 stuff ipython needs).  This would make the out-of-box experience 
  as click-and-run as possible for new users.

For non-MS platforms, as you say ipython is already pretty easy to install.  I 
already provide RPMs on scipy.org, and it would thus be trivial to copy/link 
those over to the official yum repo.  There are fink, debian and BSD 
maintainers for ipython, and this is already prominently displayed on the 
ipython main page.

So I think with respect to ipython, if there is (and there seems to be) 
consensus that people want it to be publicized as the 'best default shell' for 
scientific use, the necessary steps would only be:

1. Include it in the Python/Enthought edition bundle for Win32 users.

2. Link/copy my rpms on the yum scipy.org repo, so that yum users only have to:

   a) add scipy.org to their yum.conf file
   b) yum install scipy ipython

3. Mention it in the (yet to be written) newcomer's intro, so that people get 
used to a good interactive environment from day 1 instead of the crippled 
python shell.  This only needs to be a brief section (a couple of paragraphs, 
which I can write), since ipython already is very extensively documented. 
We'd just mention what it does, and how to get it installed together with the 
rest of scipy.

Of all the much more challenging issues the ASP project faces, ipython is one 
of the really easy ones.  The three steps above require very little work, 
since most of it is already done.  As I said, I'll gladly write the two 
paragraphs necessary for the intro guide about introducing ipython.

Incidentally, I think that much of what I said here about ipython could apply 
almost verbatim to matplotlib.  Matplotlib also wants to keep its own release 
cycle, but it would be good to make it as transparent as possible for new 
users to get it off the ground with the rest of scipy.

> Ideally, IPython should be the default Python shell, so it should
> really become part of Python.

I only wish :)

Best,

f