Improvement ideas for pixi global trampolines

[ruben-arts]

We've implemented a Trampoline for the pixi global executables exposure.

What is a trampoline

A trampoline is an executable will set the path and start the actual executable in the conda environment it was coming from. This done because we can't just run any binary in the environment without activating it.

pixi global install pixi-pack will create the following file structure for you:

.pixi
├── bin
│   ├── pixi-pack
│   └── trampoline_configuration
│       ├── pixi-pack.json
│       └── trampoline_bin
├── envs
│   └── pixi-pack
│       ├── bin
│       ├── conda-meta
│       ├── include
│       ├── lib
│       └── ssl
└── manifests
    └── pixi-global.toml

Interesting here is that the .pixi/bin/pixi-pack is a hardlink to the .pixi/bin/trampoline_configuration/trampoline_bin and that binary will read it's own file name and find the .json file that has the same name in the trampoline_configuration.
This allows the trampoline to execute the correct file when the user calls for it. The configuration tells the trampoline which file it needs to actually run and which PATH it should use. :

{
  "exe": "~/.pixi/envs/pixi-pack/bin/pixi-pack",
  "path": "~/.pixi/envs/pixi-pack/bin:.....",
  "env": {
    "PATH": "~//.pixi/envs/pixi-pack/bin:PATH",
    "CONDA_PREFIX": "~/.pixi/envs/pixi-pack"
  }
}

Improvement ideas

• Cleanup:pixi_tramoline is put in its own crate in the pixi/crates folder. But it's not part of the workspace, so it should be in the root of the repository.
• Performance: The trampoline size is a few 100 kilobytes, which should be shrinkable by a lot, we use big libraries which could be skipped if the implementation needed is written by hand. Like, the error reporting of miette is more than this binary needs.
• Automation The CI generates the trampoline binaries, but we still need to add them to the project by hand. This would be great if it could be automated so we don't make bugs by hand.

[Hofer-Julian]

@wolfv and I also identified that we could improve on our env var caching. Specifically, the PATH variable.

Currently, we cache the whole PATH and during runtime, we add entries that are missing from the cached PATH.
That can easily lead a situation where you have directories in your PATH that you don't want to have.

We could improve it in two ways:

1. Only store the diff between the PATH before and after activation. Prepend that diff to the PATH during runtime.
2. Take a PIXI_BASE_PATH into account. The PATH during runtime would then be $DIFF_BETWEEN_PATH_AND_PIXI_BASEPATH:$CONDA_ENV:$PIXI_BASEPATH. Users would set export PIXI_BASE_PATH=$PATH in their .zshrc or .bashrc

I feel like 1) would be already an improvement over the current state, and we can implement 2) if there are then still edge cases to cover.