[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