[pymvpa] Why no PyPI?

[Yaroslav Halchenko]

On Mon, 18 Feb 2013, Ben Acland wrote:

>    I am going to take the time to do a deeper investigation of buildout. It
>    looks like a potential winner. If it checks out, I'll build a recipe for
>    my lab, check it on a few platforms, then post back here if it's
>    worthwhile.

whatever is worthwhile for a lab, might benefit others ;-) so yes --
please do share your findings

Cheers,

>    Ben
>    On Feb 17, 2013, at 4:34 PM, Ben Acland <[1]benacland at gmail.com> wrote:

>      Homebrew formulas require tests, which can be more or less extensive.
>      You can run them after installing by calling `brew test foo`, but
>      they're just ruby methods, so conceivably you could just call them as
>      the final step of installation. Actually... I don't think it'd be that
>      easy. There's an easy way to find out... let me test this out on a
>      formula I'm working on right now (for shogun).
>      Nope, it's not that easy. Of course after establishing that, it's clear
>      why. Won't put the boring details here. The orthodox approach would be
>      to put in the instructions "please call `brew test pymvpa` immediately
>      after installing". Another approach would be to call `setup.py test`
>      from within the install command, which might well work.
>      Downside... homebrew only covers mac, and I'm after something
>      cross-platform here.
>      As for pip... a couple people have tried to get the pip folks to make it
>      a little more CPAN like (viz. run tests prior to installation), and
>      there's even a branch out there that does it, but as of yet it's not
>      part of the main branch. Might be dead in the water.
>      As for any package I know of... there is buildout
>      ([2]http://www.buildout.org/), which lets you run pretty much anything
>      you want as part of installation (being a full build system)... but I'm
>      not an expert on it, and apparently maintenance can be a bit of a chore.
>      On the upside, it does share with the pip+virtualenv approach the
>      benefit of providing an isolated environment, which gets at one of the
>      main issues I'm trying to address with all this bothersome questioning
>      and probing: setting up and protecting your environment on a shared
>      resource where you might not have sudo privileges. Granted, there are
>      problems to achieving that fully when it comes to installing the
>      non-python dependencies. Buildout might warrant further investigation.
>      It's the only one of the options so far that seems to be
>      cross-platform-ish, capable of installing non-python dependencies, and
>      capable of running unit tests as part of installation. But again, no
>      buildout expert here, so these advantages might crumble under closer
>      inspection.
>      Ben
>      On Feb 17, 2013, at 1:43 PM, Yaroslav Halchenko
>      <[3]debian at onerussian.com> wrote:

>        On Sun, 17 Feb 2013, Ben Acland wrote:

>            See, I knew I was stepping in it :).
>            I think I can handle that. Pip only does python stuff, of course,
>          but that
>            covers the must-haves and the strong recommendations. For the
>          optionals,
>            there's a way to define external requirements, and print a warning
>          saying,
>            "you should really consider installing this." I found a decent
>          example of
>            something that might be acceptable in the python module Shapely.
>          See this
>            gist for an example of what happens when you try to install it
>          without a c
>            library that makes it run faster:
>            [1][4]https://gist.github.com/beOn/4970435
>            Would that kind of behavior be acceptable?

>        I think so... the only hard requirement is numpy, then very desirable
>        is
>        scipy () + nose (for testing) + matplotlib (for plotting)
>        and then everything else from the link I have provided ;-)

>        btw -- does any package you know finishes "installation" by
>        unit-testing
>        the beast?  imho it would be nice as well if pymvpa gets tested as
>        installed, and in case of failure -- output of mvpa2.wtf() would be
>        provided -- this could greatly simplify any needed troubleshooting and
>        would prevent (delayed) problems with deployed pymvpa

>          If so... yeah, I think I can
>            take this on. Otherwise, I'll at least be happy to write a
>          homebrew
>            formula, but pip wouldn't make a whole lot of sense.
-- 
Yaroslav O. Halchenko
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik