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