-
Notifications
You must be signed in to change notification settings - Fork 338
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
Honor envs_dirs #2538
Honor envs_dirs #2538
Conversation
Co-authored-by: Katrin Muck <katrin.muck@tuwien.ac.at>
{ | ||
return root_prefix; | ||
} | ||
if (auto dir = find_env_in_dirs(name, envs_dirs); dir.has_value()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just checking, do we want an env
from env_dirs
even if it's not writable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you can activate it for instance (which is what the contributor initially wanted).
|
||
subcmd | ||
->add_option( | ||
"prefix_or_name", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, do we want to allow this? Is it for specific cases, or to follow e.g conda's behavior, or something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, at least for backward compatibility. It is a feature that you can do micromamba activate env
without specifying.
@@ -86,16 +169,18 @@ namespace | |||
config.load(); | |||
shell_init( | |||
consolidate_shell(config.at("shell_type").compute().value<std::string>()), | |||
config.at("shell_prefix").compute().value<std::string>() | |||
Context::instance().prefix_params.root_prefix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit lost here, why do we replace shell_prefix
with the root_prefix
? Is it because we know that we use it in here deterministically? (same for the other replacements below).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was always the root_prefix 🙃
It was that way because the same CLI option was used as a catch all root/prefix.
+ guessed_shell + R"() shells, run: | ||
$ micromamba shell init --shell=)" | ||
+ guessed_shell + R"( --prefix=~/micromamba | ||
std::string const guessed_shell = guess_shell(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Refactor
micromamba shell
to differentiate--name
,--prefix
, and--root-prefix
options (CLI backward incompatible)Make
Configuration::target_prefix
honorenvs_dirs
Switch to using
target_prefix
inactivate
andcreate
Close Respect conda settings 'envs_dirs' and 'pkgs_dirs' #2465
Close Use envs_dirs settings during environment creation #2475 (supersede)
Close
micromamba shell -p
does not work #2386Close
micromamba shell init
uses-p
for the root prefix #2442Close
micromamba shell -n myenv
broken in 1.3.0 #2271Close Handle multiple package cache and envs dirs #1110
@katringoogoo, I had to start anew due to large number of conflicts. This solves the issue of
envs_dirs
withcreate
andactivate
(with tests).Do you want to iterate on this and make sure
envs_dirs
is honored with other commands as well (install
,update
,env
...)? With the refactor of putting the logic insideConfiguration
, this could be as simple as making sure these commands usetarget_prefix
.