constructor relies on a frozen version of conda named conda-standalone. conda-standalone is built off two feedstocks:

• https://github.com/conda-forge/conda-standalone-feedstock
• https://github.com/AnacondaRecipes/conda-standalone-feedstock

We will be syncing both to conda/conda-standalone soon.

conda-standalone is not just a frozen conda. It contains some modifications:

Patches:

• noarch entry-points compatibility for Windows: Scripts/conda.exe won't be available in the PyInstaller executable, so we add it ourselves from the conda sources (conda/shell/cli-$ARCH.exe)
• Do not conda-activate the wrapped subprocess for Windows; just modify the PATH as needed.

Modified CLI:

• The frozen conda.exe contains a hook to detect whether the CLI is using a constructor subcommand (e.g. conda constructor...) and redirects those calls to a bundled _nsis.py file.

_nsis.py comes from constructor! It's a helper script to aid Windows installers with some steps, like menu items creation.

Windows' NSIS installers end up using _nsis.py in two different ways:

• Directly, via the bundled Python. This is the reason why python is ALWAYS added to the list of packages in the installer.
• Through conda-standalone's constructor entry point.

The thing is that conda-standalone already features a FULL Python installation inside the frozen executable, so there's no need to force feed Python into the installer again.

My plan is to:

1. Move the _nsis.py (and dependents) to conda/conda-standalone
2. Replace the direct calls to _nsis.py with equivalent functionality through conda-standalone
3. Do not require Python in the base environment anymore, but leave conda.exe in the installation, because it will be needed at uninstall time.
4. (At some point) Package the constructor helpers in conda-standalone as a conda plugin, so building conda-standalone is less hacky

Thoughts, @conda/constructor?

cc @wolfv - since this might affect the micromamba integrations.