[SciPy-dev] Re: ASP: Ipython in SciPy

[Fernando Perez]

eric jones schrieb:
> So, I'd vote for having a download next to SciPy's download on the 
> website for all of these tools instead of putting them in the same 
> repository.  On the windows platform, we will continue to distribute a 
> Python Enthought Edition that bundles all of these up into a single 
> download so the windows people don't have to gather them all together 
> for a single-click install.  For Linux, there is still some effort in 
> getting all the packages assembled.

This is similar to my opinion, which I wrote this morning in the original ASP 
thread.  But somehow my email seems to have fallen through the cracks in the 
discussion, so I'm going to repaste most of it here.

Now that ipython works really well under Windows, I do think it would be nice
if Enthought's python edition 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, 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.

One thing I will do for the next release is change the RPM naming scheme so 
that the package is named ipython (instead of the unnecessary IPython 
capitalization), to conform with debian's packaging conventions and the rest 
of scipy.  I just don't know how to do this, so if anyone can pass me the 
necessary distutils magic I'd appreciate it.

Note that I named ipython with funny caps simply because I thought that it 
should mean 'interactive python', and Python is capitalized, but I refused to 
fall into the stupid 'iFoo' style of names Apple has popularized.  So I ended 
up choosing IPython as the name in all the code.  But I have no strong 
feelings about this, and perhaps in retrospect it wasn't such a good decision. 
  It's too late to change the package's true Python name (code wise), but I 
can always fix the rpm distribution name to make it more in line with the rest 
of the tools.

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.

It's a bit funny that I seem to be advocating _not_ bundling ipython with 
scipy, since of all people on this list, I'm obviously the one with the 
strongest desire to see ipython become popular :)  But I want to see it done 
in a way that is best in the long term both for ipython and for scipy.

If we were to bundle ipython in the scipy rpm, then I'd have to warn users 
that if they have scipy, they can't install a standalone ipython rpm (since 
both would try to write to /usr/lib/python2.X/site-packages/IPython).  This 
would quickly develop into a set of big maintenance problems.

I really think that the right approach is to keep them as separate codebases, 
but to make their common installation so absolutely easy that it is never an 
issue for the users.

I completely agree with Joe that this has to be 100% foolproof, so that the 
scipy tutorial can _assume_ that the user is guaranteed to have ipython 
running for all the examples.  But I think we can achieve this goal quite 
easily, without entangling their codebases in a way which would cause both me 
and the rest of the scipy team headaches in the future.

Best,

f