ncoghlan
commented
2 weeks ago Resolution will be a partial implementation of #19, switching to a static data-driven postinstall script that reads a JSON layer config file from ./share/venv/metadata/venvstacks_layer.json to determine what to include in pyvenv.cfg.
sitecustomize.py will also read the file to determine:
* what
sys.path entries to add* what os.add_dll_directory calls to make (if any)
(rather than dynamically generating the sitecustomize.py file at build time)
Reading the JSON file on every startup would have been pointlessly slow, so sitecustomize.py will still be generated, it will just be generated in the post-install script for the deployed environments.
The post-install script implementation will be importable at build time, so the build environment sitecustomize.py can be generated at the same time as the venvstacks_layer.json config metadata for the deployed environment.
While working on #24/#64, I found a problem where the postinstall scripts will do the wrong thing if executed with something other than the expected base runtime environment (
pyvenv.cfggets populated incorrectly, so the layered environment ends up referencing the wrong copy of the base runtime environment).LM Studio itself does this right, so it didn't hit the problem. The test suite is doing it wrong, but wasn't failing due to the deployed environments and build environments both existing in the CI environment.
The new automatic layer versioning tests in #64 picked up the problem because the expected contents of
sys.pathnow differ between the built environments and the deployed environments fortest_sample_project, making the misconfigured environments fail their checks (on Windows - the symlinked environments on Linux and macOS still worked due to the way CPython behaves when run via a symlink, even withoutpyvenv.cfgbeing set up yet).