RFC: Disabling solves at install time

[jaimergp]

As of constructor v3, the installers relies on a bundled version of conda-standalone to perform the extraction, linking and post-link tasks of the package installation. Using a full conda executable instead of a light reimplementation brings several benefits to the table:

• compatibility with .tar.bz2 and .conda packages
• proper handling of noarch
• topological execution of pre and post link/activation scripts
• battle tested code

However, the current invocation has an unintended side-effect: a full solve is performed (again) during install time, even if the input file already contains the "environment solution".

This behaviour is responsible for at least these two issues: #319 and #456

I see three solutions here, ordered in growing complexity of implementation:

• Add --no-deps to the command. I think this still performs a full solve and might be slower than the options below.
• Use a @EXPLICIT input file with relative local paths, instead of "exact specs" (e.g. pkg=1.2.3=h123abc_0.
• Rely on a frozen conda-lock executable? 😎 Constructor essentially locks an environment and bundles it, putting a OS-specific UI/CLI on top.

I would like to gather your ideas/feedback before we start working on a solution, @conda/constructor

Thanks!

[hoechenberger]

• Rely on a frozen conda-lock executable? 😎 Constructor essentially locks an environment and bundles it, putting a OS-specific UI/CLI on top.

This sounds like an interesting idea. How mature is conda-lock?

[bkreider]

If --no-deps doesn't perform a full solve, this seems like the easiest solution.

[jezdez]

• Rely on a frozen conda-lock executable? 😎 Constructor essentially locks an environment and bundles it, putting a OS-specific UI/CLI on top.

This sounds like an interesting idea. How mature is conda-lock?

Pinging @mariusvniekerk, I believe conda-lock is stable-ish with the 1.0 out (and a good stream of releases since)?