Open jaimergp opened 2 years ago
Nice, this sounds like a great plan and should make things much more obvious.
Hi there, thank you for your contribution!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.
If you would like this issue to remain open please:
NOTE: If this issue was closed prematurely, please leave a comment.
Thanks!
Still ongoing!
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.