Python venv implementation

[zifeo]

⋊> ~/D/test on main  cd metatypedev/
⋊> ~/D/t/metatypedev on main  which python3
/opt/homebrew/bin/python3
⋊> ~/D/t/metatypedev on main  cd metatype
⋊> ~/D/t/m/metatype on chore/bump-deno-to-1.43.6 ◦ which python3
/Users/teostocco/Documents/triage/metatypedev/metatype/.ghjk/envs/default/shims/bin/python3               

However running tools like poetry shells will create a separate venv because we have not entered the ghjk one:

• can the python lib really be shared among installation ? .ghjk/envs/default/shims/lib/python3.8@ -> /Users/teostocco/.local/share/ghjk/ports/installs/cpy_bs_ghrel@0.1.0+5bcfcf5e/lib/python3.8 indicated that additional packages will be installed in the share path, clashing between project
• maybe the python shall only create a .venv (parameterized) and activate automatically the env when the project is entered (and off at exit)?

[linear[bot]]

MET-569 Python venv implementation

[Yohe-Am]

Yeahh, if you do pip install without a venv, it'll indeed modify the global share installation. It should be possible to guard against that (using file permissions maybe?),

And yeah, regarding virtual envs in general, I'm inclined to follow nix's recommendation on this. That is, provide a standard set of env hooks that users can add to make sure the ghjk environment creates/activates a virtualenv. Imagine:

// ...
import { pyEnv } from "$ghjk/py.ts"

env("parent").install(ports.something())

// pyEnv will add the python install along with hooks for virutal envs
// it's basically a mixin
env("child", pyEnv({ version: "3.13"})) 
  .inherit("parent")
  .install(ports.somethingElse())

This will require #80 to allow dynamic setting of the VIRTUAL_ENV variable. (We'll not be invoking the activate scripts directly).

The nice thing about such a simple/un-opinionated implementation is that it'll allow you to use any of the number python tooling to actually manage your dependencies.

Unlike nix, we ought to keep the ports system just for managing posix binaries/libs for now. Users ought to use use Pip, poetry or the new kid on the block, uv for managing libraries. (We ought to re-write pipi to be based on uv). Basically, treat the venv like a node_modules folder despite all the unixy thing it does.