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