RFC: Undoing constructor / conda-standalone cross "bundling" #549
Labels
pending::discussion
contains some ongoing discussion that needs to be resolved prior to proceeding
stale::recovered
[bot] recovered after being marked as stale
stale
[bot] marked as stale due to inactivity
constructor
relies on a frozen version ofconda
namedconda-standalone
.conda-standalone
is built off two feedstocks:We will be syncing both to
conda/conda-standalone
soon.conda-standalone
is not just a frozenconda
. 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
)Modified CLI:
constructor
subcommand (e.g.conda constructor...
) and redirects those calls to a bundled_nsis.py
file._nsis.py
comes fromconstructor
! 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:python
is ALWAYS added to the list of packages in the installer.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:
_nsis.py
(and dependents) toconda/conda-standalone
_nsis.py
with equivalent functionality throughconda-standalone
base
environment anymore, but leaveconda.exe
in the installation, because it will be needed at uninstall time.constructor
helpers inconda-standalone
as a conda plugin, so buildingconda-standalone
is less hackyThoughts, @conda/constructor?
cc @wolfv - since this might affect the micromamba integrations.
The text was updated successfully, but these errors were encountered: