[SciPy-User] Pylab - standard packages
Fri Sep 21 15:32:12 CDT 2012
On Fri, Sep 21, 2012 at 3:54 PM, Nathaniel Smith <firstname.lastname@example.org> wrote:
> On Fri, Sep 21, 2012 at 7:25 PM, Ralf Gommers <email@example.com> wrote:
>> On Fri, Sep 21, 2012 at 7:47 PM, Skipper Seabold <firstname.lastname@example.org>
>>> On Fri, Sep 21, 2012 at 1:36 PM, Thomas Kluyver <email@example.com> wrote:
>>>> On 21 September 2012 18:15, Skipper Seabold <firstname.lastname@example.org> 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.
I think this could be very helpful, especially with template package structure.
There once was a scikits template, but it's ages out of date, when I
last looked at it.
>>>> 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)
main failure of pip: no installation of binaries
is still my favorite (on Windows) except when it doesn't find any
> 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
> a compiler).
> (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
> SciPy-User mailing list
More information about the SciPy-User