[Neurodebian-users] NeuroFedora packaging priorities

[Yury V. Zaytsev]

> On 17. Nov 2018, at 04:20, Yaroslav Halchenko <debian at onerussian.com> wrote:
> 
>> I will checkout popcon for
>> sure. I think mricron, mrtrix3, AFNI, MNI tools and ANTs cover a lot of
>> ground in terms of broad coverage with GPL/BSD tools. Interesting but not
>> surprising on the top results. Curious how much you de-emphasize Python
>> tools (NiPy projects), not denying their awesome merits, but just because
>> everyone pushes Anaconda and/or pip installable generic packaging.
> 
> well -- I am just trying not to preach for the sake of preaching...
> Especially before singularity came about, there were no other sensible
> way to "deploy neurodebian" with all awesome python things on HPC
> running  CentOS.  So, ppl would use conda.  Also if you just want a more
> rapidly moving  (and thus more frequently breaking) python ecosystem use
> pip, want some more stability and reliability -- conda, ... but nothing
> would compare if you want stability and reliability and "All software
> made equal" - use Debian ;-) 

TLDR; Debian may be awesome, but RHEL is also awesome ;-)

Well, well, well, I want in no way to diminish the value of what you are doing for the HPC folks, but back when I was still involved, I don’t remember having any problems with Python stuff even before conda and co.

I just used gsrc (which is pretty crazy, but equally awesome... today I maybe would have  picked some nix-like stuff, but it simply wasn’t there back then) for all my non-Python software dependency needs, because the typical HPC admins just can’t be trusted with anything other than providing base OS, toolchain, and maybe an MPI build. On top of that you make a virtualenv, which got particularly easy with Python 3, install stuff from your wheelhouse using requirements.txt, and there you go.

And when I needed Python 3.3 on Bluegene/Q, I simply went ahead and ported it, damnit! Plus afterwards pestered IBM to fix kernel bugs I had to work around (pretty sure they didn’t) and upstreamed a couple of issues to the Python folks.

So it’s awesome that instead of doing this myself, these days I can just take something you made and save myself a few days of trouble (and perverse fun) of porting, but the real problem in HPC is the attitude, and specifically “hey, I have no clue about statistics, and likewise about software, but I’m getting this import error, and if I don’t get around it NOW, I will publish the paper with generated (read fake) data anyways”. Taking software out of the equation will just push the problem back into the dead salmon realm...

Sent from my iPad