[SciPy-dev] adding a nice progressbar to scipy
Travis E. Oliphant
Thu Jan 10 13:51:56 CST 2008
Fernando Perez wrote:
> Well, here we're back to the old discussion between 'integrated,
> all-encompassing packages' and modular libraries.
> The progressbar package is already in pypi, so anyone can install it with
> easy_install progressbar
> So the question is, what do we win by bundling it. Mostly convenience
> for end users. But then that means we have to put it somewhere.
> Where? Do we simply swallow it into ipython? I'm not sure the
> original developer would want that. Do we put it into
> ipython.externals (we have that for external packages we absolutely
> need). That's certainly a possibility, but then slowly ipython will
> begin to carry other third-party projects we need to sync with, etc.
> And at some point, that becomes the problem Sage already faces: you
> duplicate lots of stuff, and distributors (like Debian) start to
> complain that it doesn't make sense to have this type of
Well, at Enthought we are working on part of this problem in that we are
going to be releasing an Enthought Python Distribution which will have
all of it packaged and delivered in one place. It would be a simple
thing to add "progressbar" as something that is pre-packaged in that case.
Right now we are testing the Windows MSI and finalizing it (actually
getting an MSI that contains all these packages was way more complicated
than you might first think it should be...) The plans are for a Linux
version as well as Mac OS X version as well (although our initial focus
is corporate accounts). There will be obvious questions about how the
Linux version should integrate with other packaging systems on that
platform that we have not entirely resolved.
One potential source of difficulty for some is that we are going to
charge commercial users for long term use of the binary distribution.
Academic and hobbyist users will be able to use it for free (and that is
very important for us and so will not be changing). Commercial users
can also try it out for free as well.
Ideally, the conversation will change as this becomes more widely
available and utilized. There will still be issues to resolve in terms
of how much each package contains but there will not be quite the
pressure for the idea of a monolithic super-package that I once had for
By the way, if anybody uses Windows and would like to be a beta-tester
for the Windows binary MSI (or other platforms as they become available
over the next year), please let me know.
> In the scipy world, we've taken an approach in many ways opposite to
> sage: well-defined and separated tools that do one thing well each
> (ipython, numpy, scipy, matplotlib, etc). People are then free to
> assemble them as they best see fit. This has both pluses and minuses.
> Sage has gone the other way: include the entire universe inside, down
> to python itself, a Fortran compiler, low-level system libraries like
> termcap, etc. Sage is almost an operating system (in fact for windows
> it is, since Sage for windows ships an entire Linux distribution as a
> VMWare image). There's an undeniable advantage of convenience for end
> users here, but it also does cause problems on other fronts.
> Asking for progressbar *inside* ipython is asking for that kind of
> 'bundle everything that could be useful' approach.
> How do you see that balance? What's the perspective of others? I
> have a lot more thoughts on this question, and in fact it's something
> I hope to discuss in detail at the Sage/Scipy meeting, but I'd like to
> hear other opinions.
> Scipy-dev mailing list
More information about the Scipy-dev