[SciPy-dev] Accessible SciPy (ASP) project
Fernando.Perez at colorado.edu
Tue Nov 2 01:07:59 CST 2004
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.
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 :)
More information about the Scipy-dev