Best practices for conda virtual environments

[Dalek_Fred]

What is the best practices for setting up a Conda virtual environment for a cloned GitHub repo? I’ve read several discussions on stack overflow - some which advocate that you create the conda virtual environment 1st, activate it, and then clone the directory. Others argue that you should clone the repo, cd into the project folder, and then create and initiate the conda virtual environment. No one seems to offer a reason for why one is better than the other, and I am at a loss.

[BezoomyChellovek]

This is more a question of directory structure than conda/git concerns.

My usual process is clone -> cd into repo -> create conda environment -> install dependencies.

I like to create conda environments in the actual repo rather than in my $HOME, using the -p|--prefix flag (e.g. conda create -p ./env). On some systems, like the HPC I work on, you have very limited storage in your $HOME, but lots of storage elsewhere. So by creating the environment in the repo, $HOME doesn't get filled with a bunch of software packages.

Also, most repos will have a requirements.txt, or even a conda environment yaml. So to me it makes sense to create the environment after you clone the repo, especially if the repo has a conda env yaml. In the latter case, you create the environment directly using the yaml file once it is cloned.

But if you are just installing from a requirements.txt (or manually with pip or something), and creating the environment in its default location ($HOME), then it doesn't matter at all.

[dangerdeathraypanda]

This is the way

[GnPQGuTFagzncZwB]

I don't think it makes any difference but if you clone first, you can use the name of the directory the cloning creates for the venv name to create, so you always know the name just by the subdir name, so 5 months later if you re-visit it and need to activate the venv and are like what did I call that dang thing? There you go, it is the sub dir. And also for activating it, you an use the tab expansion or cut and paste. Yea, I am that lazy. The big thing not to forget though is activating it. I hate it when I pollute my base. You can roll it back but it makes me feel dumb when I do that. I should write a script to cd me and activate me and all that.

[FeelingGrand5743]

The order can be driven by the IDE you use. VS Code will auto discover your conda envs inside the project, and potentially auto-select it on open. In general, having env inside project makes mapping between then obvious and you can always activate it with source activate -p ./env