Closed nathanael-naeri closed 2 years ago
Interesting, and can you confirm pygobject works in the system python3.10
Good call: it does not, and the reason might have something to do with the fact that my system Python 3.10 is provided by the deadsnakes PPA on an Ubuntu 20.04 LTS system where the default system Python is 3.8.
$ python3
Python 3.8.10 (default, Jun 22 2022, 20:18:18)
[...]
>>> import gi.repository
$ python3.10
Python 3.10.8 (main, Oct 12 2022, 19:14:26)
[...]
>>> import gi.repository
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 42, in <module>
from . import _gi
ImportError: cannot import name '_gi' from partially initialized module 'gi' (most likely due to a circular import) (/usr/lib/python3/dist-packages/gi/__init__.py)
No idea how to fix that, but in any case, not caused by vext
, so we can close this issue.
No idea how to fix that
Old StackOverflow posts hint at creating 3.10 symlinks to the 3.8 shared libraries of _gi and _gi_cairo in the system's Python installation:
cd /usr/lib/python3/dist-packages/gi
sudo ln -s _gi_cairo.cpython-38-x86_64-linux-gnu.so _gi_cairo.cpython-310-x86_64-linux-gnu.so
sudo ln -s _gi.cpython-38-x86_64-linux-gnu.so _gi.cpython-310-x86_64-linux-gnu.so
But (unsurprisingly) this doesn't work, probably because the fake 3.10 libraries created that way are not the expected actual 3.10 ones:
$ python3.10
Python 3.10.8 (main, Oct 12 2022, 19:14:26)
[...]
>>> import gi.repository
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 42, in <module>
from . import _gi
ImportError: /usr/lib/python3/dist-packages/gi/_gi.cpython-310-x86_64-linux-gnu.so: undefined symbol: _PyTraceMalloc_NewReference
Yeah if you are linking from a library in a virtual env (with symlinks or vext) to a system Python, they have to be exactly the same build.
A virtualenv with system-site-packages might be something you can try falling back to.
Makes sense. A virtual environment with system-site-packages would work indeed, although I was trying to avoid that.
Closing this issue now, as it is not an issue with vext
after all.
In a virtual environment created with Python 3.10 (
python3.10 -m venv my-venv
) and initialized with up-to-date versions of pip, setuptools, and wheel (python3.10 -m pip install --upgrade pip setuptools wheel
- wheel necessary as per #84), plusvext
andvext.gi
of course, runningvext --check gi.vext
fails even though vext is enabled according tovext --status
:This was not the case with Python 3.8 (and I didn't try 3.9).
Full traceback below:
Sadly I am unable to fix this issue.