#1929 closed defect (fixed)
python-lz4 2.1 is broken, again
Reported by: | totaamwin32 | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | blocker | Milestone: | 2.4 |
Component: | packaging | Version: | 2.3.x |
Keywords: | Cc: |
Description
on win32 clean install:
Traceback (most recent call last): File "E:\Xpra\trunk\src\dist/lib/xpra/net/compression.py", line 24, in <module> import lz4 File "C:/msys64/mingw64/lib/python2.7/site-packages/lz4-2.1.0-py2.7-mingw.egg/lz4/__init__.py", line 8, in <module> VERSION = __version__ NameError: name '__version__' is not defined
Change History (4)
comment:1 Changed 4 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 Changed 4 years ago by
r20171 fixes the packaging for macos by adding the patch to jhbuild.
comment:3 Changed 4 years ago by
For reference, here are some other instances of python-lz4 gratuitous breakage: #1464, #960
The import problem has been resolved, there were other reasons for avoiding pkg_resources: Importing lz4 is very slow
We now use version 2.1.2: r20928.
comment:4 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1929
Note: See
TracTickets for help on using
tickets.
So, it turns out (unsurprisingly) that python-lz4 has changed how it gets its version information yet again - I can't remember if it's 3rd or 4th time now. And when it doesn't get its version number, the whole library fails to load!
For such a small and simple wrapper library, the number of releases and constant needless breakage is shocking.
Here's what it does now:
And here's what I replaced it with to get on with more productive things:
Let's try to deal with this in #1883 so this won't break again next time there is an update.