[SciPy-User] Pylab - standard packages

[Nathaniel Smith]

On Fri, Sep 21, 2012 at 9:28 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>
> On Fri, Sep 21, 2012 at 9: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:
>>
>> >> 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.
>
> I thought we're first talking about the non-compiler-basic-pylab. So item 2
> isn't solved.

Item 2 is easily solved by including a compiler, which is why
including a compiler is such a good idea :-). But even so, I don't see
how it would be such a tragedy if the users who clicked the "Minimal
install" link ended up getting an error saying hey, you can't install
this package unless you download a "full pylab". That still counts as
easily solved from the user's point of view, it's not an indictment of
Pylab as a whole.

> Add to your list "I work in a company, and yes they have a
> firewall, and no I don't have admin rights".

If your firewall doesn't allow you to download files over HTTP, then
you have my condolences, but I think anybody who is really in that
position is already in a sufficiently adversarial relationship with
their sysadmin that it won't occur to them to blame Pylab/Python for
the problem.

Not sure what you mean about admin rights. Except if you mean Python's
obnoxious habit of defaulting to installing things systemwide, which
is the straightforwardly-fixable problem that I was suggesting pylab
might want to intervene on in the first place.

(Did you know that at least on Linux, and with moderately recent
version of the various pieces involved, you can do 'pip install --user
<whatever>' and you just get a single-user install, no muss or fuss? I
only discovered this *yesterday*, and no idea whether it also works on
other platforms or whether there's some slightly differently-colored
hoop you have to jump through to get the same behaviour. But it's
lovely -- finally I can stop beginning every new-user tutorial with
"okay, first, let's set you up with a local virtualenv and modify your
.bashrc to activate it". If only it were the default...)

-n