[SciPy-User] Pylab - standard packages

[josef.pktd at gmail.com]

On Fri, Sep 21, 2012 at 3:54 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On Fri, Sep 21, 2012 at 7:25 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>> On Fri, Sep 21, 2012 at 7:47 PM, Skipper Seabold <jsseabold at gmail.com>
>> wrote:
>>> On Fri, Sep 21, 2012 at 1:36 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>>>>
>>>> On 21 September 2012 18:15, Skipper Seabold <jsseabold at gmail.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.

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
>> computing.
>>
>>>> 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
>> toolkits.
>
> 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

easy_install xxx
is still my favorite (on Windows) except when it doesn't find any
compatible binaries.

Josef

> 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
> setup.py...".)
>
> -n
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user