-
-
Couldn't load subscription status.
- Fork 168
Description
The python-magic PyPI package conflicts with the upstream libmagic python bindings (which are not on PyPI). Unfortunately, even if another encoding detection dependency is selected by editing the pyproject.toml file, reuse will error out if the upstream bindings happen to be installed on the system:
Traceback (most recent call last):
File "/usr/bin/reuse", line 5, in <module>
from reuse.cli.main import main
File "/usr/lib64/python3.13/site-packages/reuse/cli/__init__.py", line 7, in <module>
from . import (
...<8 lines>...
)
File "/usr/lib64/python3.13/site-packages/reuse/cli/annotate.py", line 30, in <module>
from .._annotate import add_header_to_file
File "/usr/lib64/python3.13/site-packages/reuse/_annotate.py", line 34, in <module>
from .extract import contains_reuse_info
File "/usr/lib64/python3.13/site-packages/reuse/extract.py", line 111, in <module>
_MAGIC = get_encoding_module().Magic(mime_encoding=True)
TypeError: Magic.__init__() got an unexpected keyword argument 'mime_encoding'This happens because both of the modules (the one from PyPI and the one from libmagic) are called magic, but do not have compatible API. The selection algorithm cannot differentiate between those two, and will try to use the incompatible version if that one happens to be present.
The python-magic PyPI package provides a compatibility layer (docs, code), so the most straightforward fix could be to "just" switch to using only the compat layer. However, the relevant functions are provided behind PendingDeprecationWarning, so presumably this might get removed at a future date.
Other option could be to extend the selection algorithm to poke around the API and try to determine which of the magic modules it actually has available.
I can probably submit a relevant PR, but I want to gather some feedback beforehand. Thoughts?