pew-org/pew

Problem after upgrade to 3.6

Closed this issue · 4 comments

JPFrancoia commented

Hi,
I'm on Archlinux and today, after a system upgrade, the default version of Python is 3.6. However, I always use pew when I'm coding. But today, when I tried to use pyupdater (a package that relies on ed25519), I got the following error (everything worked fine yesterday):

Traceback (most recent call last):
  File "/home/djipey/.local/share/virtualenvs/cb/lib/python3.5/site-packages/dsdev_utils/helpers.py", line 115, in __getattribute__
    return object.__getattribute__(self, attr)
AttributeError: '_LazyImport' object has no attribute 'core'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "gui.py", line 28, in <module>
    from updater import Updater
  File "/home/djipey/informatique/python/ChemBrows/updater.py", line 8, in <module>
    from pyupdater.client import Client
  File "/home/djipey/.local/share/virtualenvs/cb/lib/python3.5/site-packages/pyupdater/__init__.py", line 69, in <module>
    PyUpdater = pyupdater.core.PyUpdater
  File "/home/djipey/.local/share/virtualenvs/cb/lib/python3.5/site-packages/dsdev_utils/helpers.py", line 118, in __getattribute__
    self._dsdev_lazy_load()
  File "/home/djipey/.local/share/virtualenvs/cb/lib/python3.5/site-packages/dsdev_utils/helpers.py", line 104, in _dsdev_lazy_load
    self._dsdev_lazy_target = self._dsdev_lazy_loader()
  File "/home/djipey/.local/share/virtualenvs/cb/lib/python3.5/site-packages/pyupdater/__init__.py", line 32, in pyupdater
    import pyupdater.core
  File "/home/djipey/.local/share/virtualenvs/cb/lib/python3.5/site-packages/pyupdater/core.py", line 30, in <module>
    from pyupdater.key_handler.keys import KeyImporter
  File "/home/djipey/.local/share/virtualenvs/cb/lib/python3.5/site-packages/pyupdater/key_handler/keys.py", line 33, in <module>
    import ed25519
  File "/home/djipey/.local/share/virtualenvs/cb/lib/python3.5/site-packages/ed25519/__init__.py", line 1, in <module>
    from .keys import (BadSignatureError, BadPrefixError,
  File "/home/djipey/.local/share/virtualenvs/cb/lib/python3.5/site-packages/ed25519/keys.py", line 3, in <module>
    from . import _ed25519
ImportError: libpython3.5m.so.1.0: cannot open shared object file: No such file or directory

I created my virtualenv with the following command:

pew new cb --python=$(pew locate_python 3.5.1)

Python 3.51 should be the default version in this env. It seems libpython3.5m.so.1.0 can't be found. I looked for it on my system:

/home/djipey/.pythonz/build/CPython-3.5.0/libpython3.5m.a
/home/djipey/.pythonz/build/CPython-3.5.1/libpython3.5m.a
/home/djipey/.pythonz/pythons/CPython-3.5.0/lib/python3.5/config-3.5m/libpython3.5m.a
/home/djipey/.pythonz/pythons/CPython-3.5.0/lib/libpython3.5m.a
/home/djipey/.pythonz/pythons/CPython-3.5.1/lib/python3.5/config-3.5m/libpython3.5m.a
/home/djipey/.pythonz/pythons/CPython-3.5.1/lib/libpython3.5m.a
find: ‘/run/user/1000/gvfs’: Permission non accordée
/usr/lib/libpython3.6m.so
/usr/lib/python3.6/config-3.6m-x86_64-linux-gnu/libpython3.6m.a
/usr/lib/libpython3.6m.so.1.0

Of course, it can't be found anywhere. What surprises me is that I think it should be somewhere in /home/djipey/.pythonz/pythons/CPython-3.5.1/lib.

Could you give me a hand to solve this issue please ?

EDIT:
Downgrading, getting the file libpython3.5m.so.1.0 and putting it in /usr/lib, then upgrading to 3.6 solves the issue (it's clearly not a clean solution). However, I would like to understand: why does Python, inside the viirtualenv, look for a library in the real system ?

berdario commented

Good question

This is something due to how virtualenv/pip work, which I never bothered to properly look into

upgrade breakage is also something for why I created the pew restore command (which obviously won't work if the libraries disappeared from the system, and thus makes it not very useful)

I tried to move the .so in my /usr/lib out of the way, but I cannot reproduce the same problem

what is the output on your machine of

ldd .local/share/virtualenvs/cb/lib/python3.5/site-packages/ed25519/_ed25519*.so

?

In my case I only get

	linux-vdso.so.1 =>  (0x00007ffe187f4000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbe1ca1c000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbe1c655000)
	/lib64/ld-linux-x86-64.so.2 (0x000055cd7d442000)
JPFrancoia commented

Hi, thank you for your answer.
I have much more shared object dependencies:

ldd .local/share/virtualenvs/cb/lib/python3.5/site-packages/ed25519/_ed25519*.so
	linux-vdso.so.1 (0x00007ffd431c8000)
	libpython3.5m.so.1.0 => /usr/lib/libpython3.5m.so.1.0 (0x00007fbb028d2000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fbb026b5000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fbb02317000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fbb02113000)
	libutil.so.1 => /usr/lib/libutil.so.1 (0x00007fbb01f10000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007fbb01c0a000)
	/usr/lib64/ld-linux-x86-64.so.2 (0x000055b41dab2000)

As you can see, there is a link to /usr/lib/libpython3.5m.so.1.0 that you don't have, and that's probably why you can't reproduce the issue. Which distro do you use ?

berdario commented

I'm running Ubuntu 16.10

I'd say it's an issue of static vs dynamic linking, though if Cpython has been installed with the pythonz integration, it seems weird that the build would differ in that

I guess I could look into the script/commands used by Pythonz for the build

I also have an Arch vm somewhere that I haven't booted in 1 year, but I'm not sure if I'll find time to look deeper into this any time soon

(EDIT: I fat-fingered the "close issue" button, reopened)

JPFrancoia commented

No problem, I have a dirty fix for now.