Bug#958114: can not use because commonutil can not be imported

[Christian Kastner]

Control: clone 958114 -1 -2
Control: reassign -2 python3-liblinear

On 2020-04-18 18:16, Tiziano Zito wrote:
> The libsvm package has changed interface and can not be used anymore. With the 
> python3-libsvm package from sid the following happens:
> 
> python3 -c 'import svmutil'
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "/usr/lib/python3/dist-packages/svmutil.py", line 8, in <module>
>     from commonutil import *
> ModuleNotFoundError: No module named 'commonutil'
> 
> I think that python3-libsvm should use the same Python package structure as 
> upstream. The Debian package pushes svm.py and svmutil.py directly into 
> /usr/lib/python3/dist-packages . In the Debian package the file commonutil.py is 
> missing (it is available in the source package):

Indeed. The file is missing in the install list for python-libsvm3. This
was just an unintentional oversight.

The same oversight happened with the sister package python3-liblinear,
hence I'm cloning this bug.

> $ ls libsvm-3.24+ds/python
> Makefile  README  commonutil.py  svm.py  svmutil.py
> 
> Putting commonutil.py directly under /usr/lib/python3/dist-packages would be 
> a bad idea, I think, because of possible name clashes.

Agreed, that name is too generic for that namespace.

> Upstream is actually creating a libsvm namespace. When installing 
> libsvm using pip, the package layout is the following:
>
> libsvm
> ├── __init__.py
> ├── commonutil.py
> ├── svm.py
> └── svmutil.py

While that would solve the namespace problem, it appears to me that the
PyPI package is not maintained by upstream, but by a third party. In
support of that suspicion is the fact that upstream's documentation
(also shipped in our Python package as README) does not use this namespace.

So our choices seem to be:
  (1) upstream changes the namespace to libsvm
  (2) we stick with commonutil
  (3) we rename commonutil
  (4) we patch svmutil by merging in commonutil (which itself is brief)

(1) would be the cleanest solution, but would have to be coordinated
with upstream, which might take a while, and theoretically could be met
with rejection.

(2) is out of the question for me. (3) is simple but confusing.

(4) is probably the simplest solution, and is what happens in practice
anyway. If one checks svmutil (the only consumer of commonutil), it
imports everything of commonutil into its own namespace.


I'll give this some more thought, but the solution will probably be
implement (4), and ping upstream about (1) for some future release.

Thank you for the report!

Christian