You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As already mentioned here, in former versions of neurodocker one was able to activate an environment of choice. I propose to reintroduce this functionality. Though in theory, one could also install everything into the base environment, this doesn't work in our case (conda is not able to resolve complex dependencies, when there are already packages with specific versions installed in the base environment) and is also generally not considered good practice ("leave the base environment untouched").
On top of generally re-introducing this functionality, I would also pitch for a way that is not dependent on any files found in HOME directories. The reason for that is, that in my instiution (and certainly other research facilites)
we don't get root-rights for our machines. The only way to make sure that I am being able to modify/delete files that were created using container processes is to pass my host's user and group id to the container. That however leads to a user "inside the container" that has no home directory. Therefore there are no files that conda init could write to.
I already found a way to do this based on this comment (also see the conda docs) and it should be possible to integrate this into neurodocker. The minimum thing to do is to define:
ENV PATH="/opt/miniconda-latest/envs/env_name/bin:$PATH" where you replace env_name with the environment of your choice (should be possible to work with formatted strings here). Conda init also does a lot of cosmetics (e.g. putting (env_name) at the front but this should also be possible to hardcode.
The text was updated successfully, but these errors were encountered:
In a nutshell, the solution is to bake a list of environmental variables into the Dockerfile to imitate the behavior of conda init. The only difference is, that the first option leads to a global solution (that works both with and without the ---user flag.
As already mentioned here, in former versions of neurodocker one was able to activate an environment of choice. I propose to reintroduce this functionality. Though in theory, one could also install everything into the base environment, this doesn't work in our case (conda is not able to resolve complex dependencies, when there are already packages with specific versions installed in the base environment) and is also generally not considered good practice ("leave the base environment untouched").
On top of generally re-introducing this functionality, I would also pitch for a way that is not dependent on any files found in HOME directories. The reason for that is, that in my instiution (and certainly other research facilites)
I already found a way to do this based on this comment (also see the conda docs) and it should be possible to integrate this into neurodocker. The minimum thing to do is to define:
ENV PATH="/opt/miniconda-latest/envs/env_name/bin:$PATH"
where you replaceenv_name
with the environment of your choice (should be possible to work with formatted strings here). Conda init also does a lot of cosmetics (e.g.putting (env_name)
at the front but this should also be possible to hardcode.The text was updated successfully, but these errors were encountered: