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

Tiziano Zito opossumnano at gmail.com
Fri Apr 24 10:35:08 BST 2020


On Thu 23 Apr, 22:46 +0200, Christian Kastner <ckk at debian.org> wrote:
>> 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.

Well, even if (4) seems the most pragmatic approach, I think there are still 
some problems with it. In particular, software depending on libsvm3 would have 
to support the Debian-specific way of importing the library, along with the PyPI 
version. Assume your library/software is using libsvm. If libsvm has been 
installed with the Debian package, then the correct import is:

import svmutil

if libsvm has been installed with pip, then the correct import is:

import libsvm.svmutil as svmutil

I encountered this problem while updating the python3-mdp package, so the use 
case is pretty concrete. So maybe, before implementing (4), it would be nice to 
ask upstream their opinion about this mess (option (1))?

In general I think that the more consistency the better, so in case of doubts 
I would say that Debian should follow PyPI, or otherwise Debian or the end user 
would have to patch any script/library using libsvm if they want it to be 
portable…


Best regards,
Tiziano



More information about the debian-science-maintainers mailing list