[SciPy-User] Pylab - standard packages
Fri Sep 21 14:54:45 CDT 2012
On Fri, Sep 21, 2012 at 7:25 PM, Ralf Gommers <firstname.lastname@example.org> wrote:
> On Fri, Sep 21, 2012 at 7:47 PM, Skipper Seabold <email@example.com>
>> On Fri, Sep 21, 2012 at 1:36 PM, Thomas Kluyver <firstname.lastname@example.org> wrote:
>>> On 21 September 2012 18:15, Skipper Seabold <email@example.com> wrote:
>>> > This sounds great. A few others I usually put in a fresh install.
>>> > mpmath
>>> > sphinx
>>> I don't know about mpmath. I probably wouldn't include Sphinx in the
>>> spec, as it's important more when you're developing and releasing
>>> packages. But it does return us to the question about general-purpose
>>> Python packages. Should we require distribute, for example - or just
>>> specify that there must be a package installation mechanism?
I'd be inclined to include the core packages that might be expected
for simple package development: virtualenv, distribute, sphinx, nose.
Going back to the R example, my experience is that a *lot* of people
write and distribute tiny R packages. Including people I wouldn't have
expected too, and they're not always terribly professional, but they
sort of dip their toes in the water and go from there. We should
encourage a gentle slope from hacking together some algorithm for a
paper -> releasing that algorithm on PyPI. Putting together a simple
Python package is *really* easy once you know how -- 10 lines of
setup.py, 'python setup.py register; python setup.py sdist upload' --
and sphinx gives a compelling infrastructure for writing docs, etc.
>>> What about popular tools like requests?
> Never heard about it before just now, and not really related to scientific
>>> Or things like GUI toolkits that are difficult to install separately?
>>> Although PyQt would rather
>>> increase the minimum size.
> We're talking about the base (non-compiler) version, right? Then -1 on GUI
PyQt will generally get dragged along with matplotlib, won't it?
>> I like the idea of trying to emulate something like R's install.package
>> (eventually). This, to me, is one of the reasons it's so successful. The
>> target audience, as I think it is for pylab, is users - people that are
>> proficient at writing scripts and generally smart problem solvers but not
>> necessarily extremely great programmers. For example, I don't think there's
>> an assumption that the average R user has working knowledge of how to build
>> a package from scratch. Developers, on the other hand, don't need too much
>> hand holding to get the other tools they need - e.g., compilers, sphinx
>> probably falls in here, etc. If having things like distribute in the package
>> helps move us in this direction (would it?), then I think that's a good
>> argument for including it.
> Before something like a robust "install.package" is a reality, I'm not sure
> requiring setuptools/distribute/pip/... is useful. It breaks all the time,
> which will give new users a poor impression of Pylab (or Python).
> Python(x,y)'s solution of plugins as .exe files is much less likely to break
> if done right.
It works great for plugins that they've put together and distributed
and are up to date with the version you need and etc., but there are
>24,000 packages on PyPI. IME pip failures come down to:
- packages that use numpy.distutils but numpy isn't installed
- packages that need a compiler
- packages that have some elaborate library dependencies (like
suitesparse or whatever)
The first two are easily solved. And if that only gives people access
to 22,000 packages or so, then oh well... I can't see how it would be
better to have *no* library installation method.
I think every project I've used R on I've ended up wanting to upgrade
some package at some point. E.g. if I want pandas 0.8 and I'm using
Python(x,y), then 'pip' will probably just work, and it's currently
the *only* option (they're still distributing 0.7, but they do include
(Okay, I admit that part of this is just that I want to stop twitching
every time I see a tutorial that includes the phrase "sudo python
More information about the SciPy-User