Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reintroduce activate argument for --miniconda #537

Open
JohannesWiesner opened this issue Jul 12, 2023 · 2 comments
Open

Reintroduce activate argument for --miniconda #537

JohannesWiesner opened this issue Jul 12, 2023 · 2 comments

Comments

@JohannesWiesner
Copy link

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.

@JohannesWiesner
Copy link
Author

As already mentioned, this issue can be solved by following the solution from here:

conda/conda#12858 (comment)

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.

@github-actions
Copy link
Contributor

This issue is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale label Oct 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants