* Remove deprecated packaging and cython
* Fix some issues after cherry-picking
* Fix CI issues
* Remove test files added for v6
* Also remove test_alpha.py
The library ctypes has shipped with the python standard library since
Python 2.5, however this was still added via the `requires` keyword in
setuptools.setup. This results in a spurious requirement being created
in the .whl METADATA file, causing warnings when packaged via tools like
pex:
```
$ python3 -m pex capstone -o capstone.pex
/Users/ott/.venv/lib/python3.9/site-packages/pex/dist_metadata.py:397: PEXWarning: Ignoring 1 `Requires` field in /Users/ott/.pex/installed_wheels/2a4c7a0d4c87aceed3134ae20997a764af1811fee8e151cf5da90e0462822893/capstone-4.0.2-py3-none-macosx_12_arm64.whl metadata:
1.) Requires: ctypes
You may have issues using the 'capstone' distribution as a result.
More information on this workaround can be found here:
https://github.com/pantsbuild/pex/issues/1201#issuecomment-791715585
```
Since this requirement is outdated, it can just be removed.
When the python bindings are installed using the new wheels
infrastructure, data_files are relative to the site-packages directory
even if using absolute paths.
The following example demonstrates the bug fixed by this commit: (ran on archlinux)
```bash
$ pip install wheel # if this package is installed, wheel installation is made the default
Collecting wheel
Downloading wheel-0.29.0-py2.py3-none-any.whl (66kB)
100% |################################| 71kB 124kB/s
Installing collected packages: wheel
Successfully installed wheel-0.29.0
$ pip install capstone # this will use the wheel installation method now
Collecting capstone
Using cached capstone-3.0.4.tar.gz
Building wheels for collected packages: capstone
Running setup.py bdist_wheel for capstone ... done
Stored in directory: /root/.cache/pip/wheels/7c/d1/d0/db6e2c5ef1063aabb9de2dd8b92b4c27ee6f9fd213240099b8
Successfully built capstone
Installing collected packages: capstone
Successfully installed capstone-3.0.4
$ find /usr/lib/ -name "libcapstone.so"
/usr/lib/python3.5/site-packages/usr/lib/python3.5/site-packages/capstone/libcapstone.so
```
So the path `SITE_PACKAGES` in the `data_files` specification of the
setup.py file was interpreted relative to the python site-packages
directory. The fix for this is simple: use `/capstone` instead of an
absolute path for `SITE_PACKAGES`.
When the python bindings are installed using the new wheels
infrastructure, data_files are relative to the site-packages directory
even if using absolute paths.
The following example demonstrates the bug fixed by this commit: (ran on archlinux)
```bash
$ pip install wheel # if this package is installed, wheel installation is made the default
Collecting wheel
Downloading wheel-0.29.0-py2.py3-none-any.whl (66kB)
100% |################################| 71kB 124kB/s
Installing collected packages: wheel
Successfully installed wheel-0.29.0
$ pip install capstone # this will use the wheel installation method now
Collecting capstone
Using cached capstone-3.0.4.tar.gz
Building wheels for collected packages: capstone
Running setup.py bdist_wheel for capstone ... done
Stored in directory: /root/.cache/pip/wheels/7c/d1/d0/db6e2c5ef1063aabb9de2dd8b92b4c27ee6f9fd213240099b8
Successfully built capstone
Installing collected packages: capstone
Successfully installed capstone-3.0.4
$ find /usr/lib/ -name "libcapstone.so"
/usr/lib/python3.5/site-packages/usr/lib/python3.5/site-packages/capstone/libcapstone.so
```
So the path `SITE_PACKAGES` in the `data_files` specification of the
setup.py file was interpreted relative to the python site-packages
directory. The fix for this is simple: use `/capstone` instead of an
absolute path for `SITE_PACKAGES`.
In a virtualenv:
- site.getusersitepackages() won't import
- get_python_lib() will return the directory inside the virtualenv
- the "--user" option can therefore be safely ignored.
In a virtualenv:
- site.getusersitepackages() won't import
- get_python_lib() will return the directory inside the virtualenv
- the "--user" option can therefore be safely ignored.
These changes will allow a pypi user to locally install capstone using the --user flag. If it possible, please update the correspondent package (https://pypi.python.org/pypi/capstone/3.0.3)
These changes will allow a pypi user to locally install capstone using the --user flag. If it possible, please update the correspondent package (https://pypi.python.org/pypi/capstone/3.0.3)
Rot127