jooh/neuroconda

Conda environment for neuroimaging analysis in python, R, etc

neuroconda's Issues

rpy2 and r-stringi support

Two packages that would be useful to add are rpy2 (this worked only when I installed it from conda-forge) and r-stringi (which didn't work from conda-forge, only from r). The second is required as a dependency for quite a lot of packages, for example BayesFactor

Support for a python IDE that isn't jupyter lab would also be very useful (some basic functionalities are missing in jupyter lab)

Thanks!

Full CD of neuroconda.yml

At the moment it's quite possible for neurconda.yml to be stale with respect to neuroconda_basepackages.yml. It might be better to drop neuroconda.yml from the repo entirely, and consider it a build asset instead (perhaps together with a conda pack archive). For this we would need an action that adds the release asset, or perhaps creates the entire release.

Use conda lock to make builds reproducible

At the moment we unnecessarily invoke the solver when installing the environment from neuroconda.yml. The environment is already constructed to be solvable, and all versions are pinned, so this step does little except find the current builds for each package. We could probably live without that.

Perhaps we can instead use conda-lock to construct a lock file. This basically boils things down to a list of paths, which can be installed far more quickly.

It would also make it possible to run the builds on OS X, since conda lock has a cross-solver.

The key limiting factor of this approach is that pip files are not supported. Until this is resolved I don't think this is workable for us.

conda/conda-lock#4

Non-conda binary support

We currently support non-conda packages by modifying the user's PATH with env_vars.{sh,csh}. As of conda 4.7.12 this works in env_vars.sh but not in env_vars.csh (see this issue at conda).

The cleanest solution to this is probably to bundle the environment and all the other dependencies into a container image.

Specifying environments with builds and labels/broken instead of no-builds

It's quite common that Conda environments break (ie, can't be re-built from the YAML) due to conda-forge labelling one of the builds as 'broken'. So far the workaround for this has been to export the YAML with the no-builds flag. So we pin release versions, but not builds.

For reproducibility, it might be preferable to keep the builds in, but add the labels/broken channel to the spec instead. This way, the exact same environment should keep building, at least for as long as the conda-forge channel stays live...

The catch is that sometimes builds are marked as broken for very good reasons! And it's nice to benefit from fixes when they do happen. I suppose the situation is similar to pinned dependencies in a requirements.txt for a library. There is nothing to stop a package maintainer from changing what code that release corresponds to on Pypi, that is, there are no strong guarantees that pinning the version will mean always retrieving the exact same library. Perhaps it's best to leave bit-by-bit reproducibility for container images.

Undecided on this one.

Adding FSL to path shadows conda fsleyes install

With Conda 4.6.3, the new default behaviour of the conda activate script is to activate the conda environment first, then source the env_vars script that we use to ensure non-conda packages such as FSL are on the path. This means that the conda fsleyes gets shadowed by the FSL install fsleyes (which is generally broken, especially when run inside our conda environment).

In general, manipulating PATH during these activate.d script hooks is probably unwise as it's not really what they were intended for, and it breaks conda's deactivate behaviour (we can't unset these path changes, see conda #3915 and #7026). Long-term we should probably keep neuroconda as a strict conda environment and setup a neurodocker container to handle the other shell environment dependencies. The key drawback of this is that we lose native Matlab support.

For now, it's probably best to steer clear of the activate.d script hooks.

brms - missing a compiler?

Just to log this -
With neuroconda R on the CBU setup, I think this error means that a wrong/missing GNU compiler is being pointed to? i.e. unrecognized command line option ?-std=gnu++14?

R Package: brms
Code from this tutorial: https://github.com/paul-buerkner/brms

> library(brms)
Loading required package: Rcpp
Registered S3 method overwritten by 'xts':
  method     from
  as.zoo.xts zoo 
Loading 'brms' package (version 2.10.0). Useful instructions
can be found by typing help('brms'). A more detailed introduction
to the package is available through vignette('brms_overview').
> fit1 <- brm(count ~ zAge + zBase * Trt + (1|patient), 
+             data = epilepsy, family = poisson())
Compiling the C++ model
Error in compileCode(f, code, language = language, verbose = verbose) : 
  Compilation ERROR, function(s)/method(s) not created! g++: error: unrecognized command line option ?-std=gnu++14?
make: *** [/imaging/local/software/miniconda/envs/neuroconda_2_0/lib/R/etc/Makeconf:175: file437b1d17f5e1.o] Error 1
In addition: Warning message:
In system(cmd, intern = !verbose) :
  running command '/imaging/local/software/miniconda/envs/neuroconda_2_0/lib/R/bin/R CMD SHLIB file437b1d17f5e1.cpp 2> file437b1d17f5e1.cpp.err.txt' had status 1
Error in sink(type = "output") : invalid connection