[SciPy-dev] adding a nice progressbar to scipy

[Travis E. Oliphant]

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
> double-packaging.
>   

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 
SciPy.

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.

-Travis O.



> 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.
>
> Cheers,
>
> f
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev@scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>