Suggestion for "02 Working with Environments"

[nsultova]

From the material it did not become clear for me why creating projects in subfolders is beneficial.
Compared to the drawbacks it seems like one should have very good reasons to do so.

"Placing Conda environments outside of the default ~/miniconda3/envs/ folder comes with a couple of minor drawbacks. First, conda can no longer find your environment with the --name flag; you’ll generally need to pass the --prefix flag along with the environment’s full path to find the environment."

..also commands like conda env list do not work when placing environments out of the default location. (as another example)

Afaik its really a matter of taste and having different names + export environments also has advantages.

I'd suggest to really point out the advantages or maybe map both methods to examples and explain which method is better suited for which example.
Also, in the further course switches between different location variants are distracting from the actual topic covered and might be rather irritating to participants. I'd suggest here to focus on one single variant (either conda create --name python36-env or conda create --prefix ./env ) and strictly stick to it, adding the alternative execution method as additional material instead.

[davidrpugh]

@nsultova Thanks for the feedback. I agree that I need to do a better job of selling the reason for creating Conda environments in subfolders of project directories.

AFAIK the conda env list command still works as expected: all environments will still be listed whether they are created using conda create --name or conda create --prefix or conda env create

For better or worse, the materials as they currently stand consist entirely of my personal preferences. It is nice to get feedback from others so I can understand where my personal preferences might not generalize well.

[nsultova]

@davidrpugh Thank you a lot for the quick and thoughtful answers, I rechecked the conda env list by building a fresh example from scratch and it worked actually as you described:

                          /Users/nea/PROJECTS/test_conda_subfolder/env
base                   *  /Users/nea/miniconda3
env_create_with_name      /Users/nea/miniconda3/envs/env_create_with_name

I'd be really curious about what let you to choose the method you described, there might be use-cases I simply haven't run into yet. In my experience having the environments created with names and without prefix has the advantage of being visible at any point, so when I work on different projects in parallel I know exactly which environment I am in. I have, for example, a playground-env which I activate for different test-scenarios and which I wouldn't know how to manage if I used the subfolder approach (yet).