add support for multi_env installers

[jaimergp]

Closes #359 (possible solution)

---

In this PR I suggest adding a new keyword, extra_envs, that allows a user to specify additional environments in the same installer. It has some rules:

• extra_envs is a mapping of environment names to environment creation options. The options map supports:
  • specs, channels, channels_remap, user_requested_specs, exclude: same as the global value
  • menu_packages support is planned but not implemented yet (we need the menuinst stuff in place for a cleaner implementation)
• It requires conda on specs (either explicitly or implicitly, but better be explicit).
• ignore_duplicate_files will always be considered True

This approach guarantees backwards compatibility at the expense of a slightly more complicated install logic. The other option would have been reworking ALL specs-based installations to follow the envs mapping (including base). Maybe in a (much needed) refactor in the future.

[larsoner]

Would this require #474 (and thus conda/conda#11035 and conda/menuinst#91)? I'm having a bit of trouble following... I guess all of conda/ceps#8 should be merged around the same time to enable "new menuinst"?

[jaimergp]

Yep. The new menuinst support will be trickier to land, as it requires sync across many projects.

[larsoner]

This one needs a rebase/merge now

[jaimergp]

So I added some tests to ensure things were working ok and I found out that exclude and extra_envs won't be good friends :(

The way constructor works is the following:

1. The installer unpacks the cache of packages and some synthetic channels repodata that only contain the needed bits.
2. Then it calls conda-standalone with a list of specs that exactly match the existing packages on cache. This is not a list of paths (e.g. python-3.10-h123456.tar.bz2, but a list of specs like python=3.10=h123456).

• This means that conda-standalone WILL use the solver, which guarantees that the request is satisfiable and the environment is not shipped broken to begin with.
• I am not sure why this is needed. I think it has to do with updating installations from an installer, but in some platforms this is actively prevented (Windows, MacOS PKG), so again, not clear.

3. The thing is that if we exclude non-leaf packages (a package that is a dependency of some other package in the same environment), we can't satisfy the solve and it breaks the installation.
4. Additionally, if we mix extra_envs and exclude, since the synthetic channels and pkg cache will be shared across environments, there's a chance that the solution of one environment provides the packages that were excluded in other envs.

• For example: environment A ships python 3.8 from conda-forge but excludes tk. Environment B ships python 3.8 too, but doesn't exclude tk. When installing environment A, tk will be indeed found in the channel cache because it was needed for environment B. So both A and B will have tk, despite the exclusion.

To sum up, what I've done is the following:

• exclude can only be specified at the global level.
• If extra_envs are in use too, they will inherit the global exclude value to ensure they do not undo the exclusion accidentally (as commented in point 4 above).
• Extra envs won't error out if a package that needs to be excluded is not found in them (it does error out for the base environment).

---

Additionally, I found out that conda-standalone WILL inherit the user configuration in ~/.condarc if it existed, which can change the behaviour of the solver (e.g. strict vs flexible priority). This needs to be fixed in conda and conda-standalone; i.e. provide a flag so no condarc file is loaded and it really works "standalone". But that's worth its own issue.

[jaimergp]

@larsoner Ready for your eyes now :)

[larsoner]

I finally read through the code and it looks reasonable to me, and is tested by an example and things are green. Feel free to merge unless you want someone else to look @jaimergp !

[jaimergp]

Thanks @larsoner! We'll merge for now. Hopefully we can re-enable the excludes once I figure out the solver issues mentioned in #319

[scottwsides]

So the NSIS changes recently to constructor fixed the windows install issue and was working as of a couple of days ago. I just rebuilt... and windows is faiiling again due to "anaconda directories not being initialized". I suspect this commit (since its so recent has broken windows again). I'm buildng from trunk.

[jaimergp]

@scottwsides Please create an issue with full details about your input file, full logs and screenshots of the error if necessary. Thanks!