Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build as one dir #93

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Conversation

jaimergp
Copy link
Collaborator

@jaimergp jaimergp commented Aug 29, 2024

Description

Trying to reduce the startup times of the self-extracting archive, I was looking into "caching" the extraction directory like we do in the Nuitka PR. However, pyinstaller is against this (too many things can wrong), so instead they recommend using the onedir packaging approach.

Under this mode, we no longer obtain a conda.exe self-extracting archive, but the following tree:

- conda.exe  # the executable bootloader
- _internal/
  - ... # all libraries and data files

It's essentially the unpacked directory, with an executable entry point. I was thinking that we could have conda-standalone distribute this tree under $PREFIX/standalone_conda and then teach constructor to also copy _internal if present. Then we stop paying the extraction cost for every execution.

Then a second opportunity opens up: this could be a frozen base environment! conda doesn't recognize its own prefix as an environment with the current code. We just need to teach it to stop using base as a writable location. The base-equivalent location can be mocked via the CONDA_ROOT_PREFIX (and that's what I've done in the entry point here). Maybe we need to fix a couple bugs with the Windows entry points and whatnot, but that's doable.

Also this is easier to debug and optimize. Just realized the mamba bindings end up pulling the whole libicudata with its nice 30MB library 😂 Not sure if that's needed but for sure micromamba doesn't weigh that much (11MB in my macOS).

Anyway, a little experiment and food for thought: what if the conda installer simply provided this tree:

$INSTDIR/
  _internal/
  envs/
    default/
      ... a writable base-like environment, configured as default
  pkgs/
  conda[.exe]

Shortcomings:

  • Shell activation needs a revamp (e.g. something like conda-workon)
  • Plugins need to be handled carefully (see https://github.com/orgs/pyinstaller/discussions/8190). We might need to provide a special plugins/ env where we mock and freeze the exact contents of the conda.exe application (we know this at build time). Then folks can install their plugins there. To be seen: how to handle conda updates + plugins.

Checklist - did you ...

  • Add a file to the news directory (using the template) for the next release's release notes?
  • Add / update necessary tests?
  • Add / update outdated documentation?

@conda-bot conda-bot added the cla-signed [bot] added once the contributor has signed the CLA label Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla-signed [bot] added once the contributor has signed the CLA
Projects
Status: 🆕 New
Development

Successfully merging this pull request may close these issues.

2 participants