pkgxdev
`uv venv` and `python` issues
❯ mcd $(mktemp -d --dry-run)
❯ pkgx uv venv
Using CPython 3.13.3 interpreter at: /home/felipecrs/.pkgx/python.org/v3.13.3/bin/python
Creating virtual environment at: .venv
Activate with: source .venv/bin/activate
❯ source .venv/bin/activate
❯ which python
/tmp/tmp.EVtZvLgPQ3/.venv/bin/python
❯ realpath $(which python)
/home/felipecrs/.pkgx/python.org/v3.13.3/bin/python3.13
❯ python --version
python: error while loading shared libraries: libpython3.13.so.1.0: cannot open shared object file: No such file or directory
I don't know what it would take to fix this, but it would be tremendously good if it could be fixed. Otherwise, it doesn't seem like pkgx can be used for Python in development environments (which would be awesome, since pyenv is really bad).
- Related: https://github.com/pkgxdev/pantry/issues/7733
@jhheider, maybe one workaround (seems kinda hacky) would be to turn the python program of the python pkg into a pkgx shim somehow? This way, when invoked from the venv, python binary would still be going through the pkgx shim.
I believe the issue is with libpython paths. Sadly, I haven't found a great solution (static python breaks other things), other than copying libpython into the venv. Happy for more ideas, though.
The problem is venvs over venvs get tricky as they add and discard data from each other. It's even weirder on macOS, where DYLD_LIBRARY_FALLBACK is prevented from propagating more than one level by the OS.
I may have fixed this for pantry^2, I remember looking into something or other. All the same what is the issue specifically do we know? The python that is referenced should know where to find its own .so.
