[pymvpa] Why no PyPI?

Ben Acland benacland at gmail.com
Sun Feb 17 06:29:07 UTC 2013


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:

https://gist.github.com/beOn/4970435

Would that kind of behavior be acceptable? 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.

On Feb 16, 2013, at 8:44 PM, Yaroslav Halchenko <debian at onerussian.com> wrote:

> 
> On Sat, 16 Feb 2013, Ben Acland wrote:
>> Howdy folks. This is my first post, and it's a dumb one, so I'll keep it short:
> 
>> Why haven't you submitted PyMVPA to PyPI yet? I'm guessing it's something you've considered - sorry if this is a redundant question. But it would make using PyMVPA along with virtualenv a lot easier across platforms. Some tweaks to setup.py to add the dependency list, and hey-presto. Or... that's how it seems.
> 
> no -- that probably just "would be it"... but it would also bring more
> work for us to support those trying to install it via pypi and running
> into problems while actually using PyMVPA:  we do have few extensions to
> build (libsvm, smlr), and for the better use other optional dependencies
> better be available -- look at
> https://github.com/PyMVPA/PyMVPA/blob/master/mvpa2/base/externals.py#L492
> for the list of them.  We do have a somewhat extensive testing to
> guarantee that PyMVPA would still function nicely just with limited
> functionality when those optional dependencies are present, but those
> installations might feel crippled.  So we are primarily orienting
> ourselves for deployments on platforms with somewhat a guaranteed
> coverage of those dependencies and sane upgrade/bug reporting
> procedures, e.g.  Debian-based (with our own NeuroDebian layer on top
> ;-) ), where we have a much better handle of things.  Also serves us a
> good reason to promote use of the NeuroDebian VM for people on OSX and
> Windows boxes, where they simply might now know what they are missing by
> staying away from Debian.  As a result, in the last years we got
> virtually no complaints about installation problems, got more users of
> (Neuro)Debian -- and everyone just happily does their research ;)
> 
> We know people who deploy PyMVPA on other systems (including OSX) simply
> via 'git clone + make' and it generally works fine, but they do run into
> the problems at different corners.  E.g. absent "compatible" lapack
> builds hurt some hyperalignment cases etc.
> 
> But if someone could step in and contribute here necessary for PyPI mods
> + promise of the future support of such installations (on this
> list) -- I think we would not object to accept such a contribution
> ;)
> 
> Hope this makes sense.
> 
> Best regards,
> -- 
> 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        
> 
> _______________________________________________
> Pkg-ExpPsy-PyMVPA mailing list
> Pkg-ExpPsy-PyMVPA at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-exppsy-pymvpa

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-exppsy-pymvpa/attachments/20130217/03737e2a/attachment.html>


More information about the Pkg-ExpPsy-PyMVPA mailing list