Extract environment list code into the common module to allow reuse

[tswicegood]

Was curious more than anything about what it would take to extract this code and create a conda envs command in place of conda info -e. This maintains the old behavior, but adds a new envs sub-command.

[ilanschnell]

I don't see a strong argument for adding (yet another) sub command to conda.

[tswicegood]

It was just a different approach to the existing way. My first instinct to see a list of environments in conda was to type conda envs. I had to ask how to get a list to realize it was a parameter on conda info.

That's not a strong argument, but its the best I've got right now. Depending on how much you guys plan on doing with environments, this could serve as the jumping off point for interacting with them (conda envs destroy, conda envs clones, and so on).

[asmeurer]

There are ways to do those things, but they are also buried in subcommands. It would probably be cleaner this way.

[tswicegood]

As someone coming to conda from virtualenv+virtualenvwrapper, having a subcommand that's a first class way to interact with envs would make the most sense to me.

[asmeurer]

"How do I list all envs?" seems to be a pretty common question. That to me indicates that maybe this should be a little more publicly exposed.

[ilanschnell]

So basically conda envs would be a shortcut for invoking other existing commands.

[joelhullcio]

+1 for this direction. I have brought this up before also. It makes sense.
conda env list - list all envs from all known env locations
conda env clone - copy an env to a new env
conda env create - create a new env
conda env remove - remove an env
conda env update - update all packages in an env
conda env zip - create a bz2 zip file of the env package meta data so the env info can be shared or archived. The create and clone commands should take the output from this command as input.

[asmeurer]

Just so we're clear, all of these features already exist. They are just buried in subcommands (except for conda create).

[joelhullcio]

I understand. It just seems like a cleaner interface it we group them together. Easy to adopt, understand, use, sell and document.

FWIW, I prefer "conda env" over "conda envs" but that may be a minor thing.

[tswicegood]

@joelhullcio ya know, I think I do to having typed out envs a couple of times. Let me change it.

[asmeurer]

envs only makes sense if it's the one command to list. If it's a higher level command it should be env.

[tswicegood]

@asmeurer I didn't know that all of those commands already existed. I'm gonna add a subcommand parser to this and add env list and make it the default to provide the skeleton for providing a second (new?) home for those other commands.

Again, I think it just comes back to what you're coming from. In venv it's all about the environment, so working explicitly with that via a separate command it what makes sense to me.

[asmeurer]

conda env list - list all envs from all known env locations

conda info -e

conda env clone - copy an env to a new env

conda create --clone

conda env create - create a new env

conda create

conda env remove - remove an env

conda remove --all

conda env update - update all packages in an env

conda update --all

conda env zip - create a bz2 zip file of the env package meta data so the env info can be shared or

I'm not sure about this one, but I think it might exist.

(those all require -n or -p as well)

[tswicegood]

Talked with @ilanschnell a bit about this. What I'm going to do is pull the new conda env command out of this PR but leave in the refactoring of conda info, then create a conda-env package similar to conda-build. Anyone who's interested can help there, and once we've got a few more features we'll revisit the conversation about merging the command into the default install.

[tswicegood]

FYI, I've created a conda-env package. It relies on the extraction of handle_envs_list in this branch to work.

This now simply extracts some code to make it more reusable.

[tswicegood]

@ilanschnell @asmeurer -- going through some older code I had written around environments. I'd really like to get this code merged in. It provides the same behavior (conda info -e works as it currently does), but it provides an API for creating a list of environments.

FWIW, this could be further refactored to break apart creating the list of environments and displaying, but that's another step. This works as an incremental step toward a more usable external API.

[asmeurer]

This shouldn't be run if output=False.

[tswicegood]

Doh -- good catch.

[asmeurer]

Sure. This is a pretty innocuous change.

[tswicegood]

Output issue with the stray print() has been fixed. This is ready to merge.

[tswicegood]

Thanks!

[github-actions]

Hi there, thank you for your contribution to Conda!

This pull request has been automatically locked since it has not had recent activity after it was closed.

Please open a new issue or pull request if needed.