PR: Allow activate-environment to be a path

[bollwyvl]

This follows up on #136 where we might want to allow for activate-environment to be a --prefix rather than a --name argument to various conda commands.

Also removes some dead code which was using --name, and tweaks some more docs and typos in log messages.

Of worrying note: I have now seen at least one 403 from the GitHub API when requesting the miniforge releases, despite my best efforts at caching. We probably need to:

• have a hard-coded "version of last resort" (the one where it dropped msys2 would be a good one :P)
• throw some weight on Download page on conda-forge.org conda-forge/miniforge#76
• use git to list tags and build URLs from that... but we might pull pre-releases, etc.

[goanpeca]

@bollwyvl I did not understand the issues before, querying Gtihub API is expensive as you have now noticed.

Why do we need the miniforge releases?

We should just build the URL from what the user requests (variants etc) and fail with unknown version if it fails, no need to provide all possible releases withe the API query (if that was the purpose of it?)

[bollwyvl]

Why do we need the miniforge releases?

At present, miniforge-version is not required, though of course we could: demanding a version seems like it might be less nice for the simplest use case. Unless we do, we need to get a version from somewhere as there is no latest at a predictable URL. Having the page on the above linked issue would give us that, as would hard-coding a version-of-last-resort... it seems to be getting released more often than miniconda.

[goanpeca]

At present, miniforge-version is not required, though of course we could: demanding a version seems like it might be less nice for the simplest use case.

Might be less nice, but is what you have to provide to overcome the unnecessary problems with the API and havig a page with all that infi (not happenning soon form what I just read?) so I prefer going with explicit over implicit here :)

we have miniconda-version already, so having a miniforge-version seems only natural, and would save us from any issues with APIs. If another source of more reliable info becomes available in the future we can the improve using that but for 2.1 I would rather have the miniforge-version requirement.

[jaimergp]

This might not be as nice and convenient for the user but what if we deprecate miniconda-version, miniforge-version, miniforge-variant and friends and just expose installer? This could be either a URL to a constructor-derived installer, or a keyword like Miniconda-4.12 or Mambaforge-4.12.

If finding the right installer URL is tricky, we could collect a list in our up and coming fancy docs.

[bollwyvl]

rather have the miniforge-version requirement.

Sure, sounds good. seems out of scope for this PR, will do another... one thing we can do then is have a default miniforge-variant of Miniforge, so it would still only be a single input to get "vanilla" conda/cpython at a particular version.

[goanpeca]

Sure, sounds good. seems out of scope for this PR, will do another... one thing we can do then is have a default miniforge-variant of Miniforge, so it would still only be a single input to get "vanilla" conda/cpython at a particular version.

Agreed!

---

@jaimergp let's explore our options on another issue :-p

[goanpeca]

Is this ready for review @bollwyvl ?

[bollwyvl]

deprecate miniconda-version, miniforge-version, miniforge-variant

i feel like deprecation makes people sad... because fixing ci that used to work makes people sad. and the URL structures are fairly different between them, anyhow, even though they both come out of constructor. another reason i like the separate ones is that it becomes easy to use github search for examples when you have semantically-rich strings.

[bollwyvl]

Is this ready for review

yeah, unless we want to sneak anything else into the tests... i guess I haven't tried giving it a base env, might break the world...

[bollwyvl]

oh, and @goanpeca, re: #136: can you comment on why we always add $CONDA/condabin to $PATH?

[bollwyvl]

Looks like we need to keep condabin... will revert... specifically, was needed for bash on windows... not exactly #136, but i don't sowing future problems windows support issues...

[goanpeca]

is utils.isBaseEnv also checking for an empt string env?

[bollwyvl]

/** Names for a conda `base` env */
export const BASE_ENV_NAMES = ["root", "base", ""];

[goanpeca]

One question, otherwise looks good :)

Thanks @bollwyvl !