[saifulislampi]

Summary

Add initial pixi-pack support to poncho_package_run while preserving the
existing conda-pack behavior.

For a Pixi archive, the runner:

1. detects the root-level pixi-pack.json;
2. locates a staged pixi-unpack executable;
3. unpacks and activates the environment; and
4. starts the requested command inside it.

pixi-unpack is transferred using the existing factory option:

vine_factory \
  --poncho-env environment.tar \
  --wrapper-input /path/to/pixi-unpack

Test scenario

Import an environment.yml, create the Pixi environment, and pack it:

pixi init pixi-workspace --import environment.yml
pixi install --manifest-path pixi-workspace/pixi.toml
pixi-pack --platform linux-64 pixi-workspace/pixi.toml

Then start the factory:

vine_factory -T local \
  --manager-name "$MANAGER_NAME" \
  --min-workers 1 \
  --max-workers 2 \
  --cores 1 \
  --poncho-env "$PWD/environment.tar" \
  --wrapper-input "/path/to/pixi-unpack"

Current limitation

pixi-unpack must currently be supplied explicitly with --wrapper-input.
Factory-side automatic staging can be added separately.

[btovar]

I think that if pixi-unpack is not inside the expanded directory, then it is not a valid poncho package in pixi format? The only things you should need for poncho are tar + decompress tool + poncho_package_run + tarball?

[btovar]

poncho packages are not conda packages. They are constructed with some other support with environment variables, etc. This pr wants to support pixi-pack environments directly?

I rather have poncho_package_create modified to get an argument --format conda or pixi and modify poncho_package_run as little as possible.

[dthain]

💯 Poncho packages should be opaque, self-contained objects that require only poncho_package_run to deploy.