lmstudio-ai / venvstacks

Virtual environment stacks for Python
https://lmstudio-ai.github.io/venvstacks/
MIT License
1 stars 0 forks source link

Add relative paths to metadata for post-install script execution #19

Open ncoghlan opened 2 weeks ago

ncoghlan commented 2 weeks ago

Adding the local-export support showed that using the venv Python to run postinstall.py to regenerate pyvenv.cfg is unreliable on Windows (as whether or not it works depends on exactly how Python is set up in the Windows installation). It only works on other platforms because the Python "binary" in the venv is a symlink to the real binary in the base runtime environment.

The local-export feature works around that by using the already set up build environment to run the exported environment's postinstall.py.

test_minimal_project relies on the fact there's exactly one runtime environment defined in that test case, and falls back to using that if using the unpacked environment's own Python binary fails.

The archive and environment metadata should be updated to include three new fields, all relative to the installed environment's base folder rather than to the metadata file:

With those fields added, local environment exports and consuming applications can always use base_python and postinstall_script to finish the export process, while app_python can be used to run application launch modules.

ncoghlan commented 1 week ago

For ease of access, it may be worth saving a subset of the layer metadata to the share/venv/metadata folder proposed in #17.

Specifically, starting from unpacking the application layer archive, an installer should be able to work out:

Each framework environment would need to report:

And each base runtime would need to report:

Suggested file name would be share/venv/metadata/venvstacks_layer.json

ncoghlan commented 1 week ago

Another enhancement this change would unblock is to make even layered environment archives fully compatible with the tar_filter extraction filter.

While #23 adds that for the base runtime archives, layered environments currently still rely on external symlinks to the underlying Python implementation.

If postinstall.py were to always be executed with the base runtime directly, then the external symlink could be omitted from the archve, and the app_python and base_python metadata fields could be used to recreate the missing symlink from the post-installation script.

Framework layers wouldn't need to recreate the symlink, since everything executed on a deployed system should be running in an application layer environment.