trolldbois
ctypeslib2 breaks python-ctypeslib on debian 8
In short, ctypeslib2 implements a module named ctypeslib, which clobbers the legacy ctypeslib module without providing backwards compatibility. This breaks existing workflows and prevents their straightforward transition from gccxml to clang.
Example:
# h2xml --help
Usage: h2xml includefile ... [options]
Options:
-h, --help show this help message and exit
-q, --quiet
-D NAME[=VALUE] macros to define
-U NAME macros to undefine
-I DIRECTORY additional include directories
-o XMLFILE XML output filename
-c, --cpp-symbols try to find #define symbols - this may give compiler
errors, so it's off by default.
-k don't delete the temporary files created (useful for
finding problems)
#
# pip install ctypeslib2
Downloading/unpacking ctypeslib2
Downloading ctypeslib2-2.1.4.tar.gz (46kB): 46kB downloaded
Running setup.py (path:/tmp/pip-build-dmhvZK/ctypeslib2/setup.py) egg_info for package ctypeslib2
Requirement already satisfied (use --upgrade to upgrade): clang>=3.7 in /usr/local/lib/python2.7/dist-packages (from ctypeslib2)
Installing collected packages: ctypeslib2
Running setup.py install for ctypeslib2
changing mode of build/scripts-2.7/clang2py from 644 to 755
changing mode of /usr/local/bin/clang2py to 755
Successfully installed ctypeslib2
Cleaning up...
#
# h2xml --help
Traceback (most recent call last):
File "/usr/bin/h2xml", line 3, in <module>
from ctypeslib.h2xml import main
ImportError: No module named h2xml
I would suggest that the module provided by ctypeslib2 should be called ctypeslib2 if it is not a functional replacement for the existing ctypeslib module.
My opinion is that h2xml's xml output is not the primary function of ctypeslib. Python code is the primary output. But I can see your point, regarding breaking workflows.
The XML produced by h2xml is that of GCCXML DTD(unofficial) if I remember correctly. That output would not be produced by a clang-enabled ctypeslib.
So indeed, there is a break in backward compatibility. Similar to a major version upgrade. Which it is. Therefore the original version shouldn't be installed at the same time. But I don't control pip's ctypeslib package... So...
Possible solutions:
Add version conflict in package? PEP-0345
Use namespace package and keep both gccxml and clang solutions PEP-0420 if that means being able to distribute ctypeslib2-clang and ctypeslib2-gccxml as two different package in the same namespace see Some namespace package solution. Default (empty) ctypeslib2 package to ctypeslib2-clang using dependency
Totally get what you're saying, and you're right: ctypeslib/gccxml exposed implementation details through its interface in a manner that seems to preclude building a drop-in replacement from clang.
Otoh, my point's just that ctypeslib/gccxml and ctypeslib2/clang could co-exist side-by-side peacefully were it not for the clashing package names (c.f. PEP432.)
All that said, I'm not even sure that this is an issue that wants be fixed; my purpose is mostly just to document that error message and this explanation in case anyone runs into the issue in the future. Cheers!
Well thanks for the issue report. It is an issue and I will try to implement something that improves the current unsatisfying (by my standard) situation. Issue report is always appreciated ! thanks
Just wanted to note that I'd been using h2xml and xml2py in a makefile, and was burned by this when upgrading to clang (which seems to be the way forward.) Old builds broke. I decided to hack the h2xml and xml2py commands in /usr/bin and put the old ctypeslib earlier on the path in those scripts. (sys.path.insert; a bit clunky but works) I'm not sure such a solution could work in a more general sense.. but in my install the old and new ctypeslib modules are both there and can both be used with different paths for each. (The clobbering only happens in the path ordering.) Some better way to uniquely specify which package you want would be nice too. Peacefully coexisting is always welcome. Installing ctypeslib2 as ctypeslib2 (original suggestion) makes the most sense to me. We did figure a way to get clang2py to do the same job, so not a biggie. PS: thanks for the useful software!
