* Package name : python-louvain-igraph Version : 0.7.0 Upstream Author : V.A. Tragg <vincent@traag.net> * URL : https://github.com/vtraag/louvain-igraph * License : GPL-3+ Programming Lang: (Python Description : Louvain is an algorithm for methods of community detection Louvain is a general algorithm for methods of community detection in large networks. . This provides a python module named 'louvain'. This is the version of louvain used by ScanPy https://scanpy.readthedocs.io/en/stable/ It's also based on igraph and not networkx like the other louvain implementation python-louvain. It should probably live in the Debian med team.
Hello, The fairly popular (in the world of bioinformatics) ScanPy package uses a Python version of the louvain clustering algorithm implemented by: https://github.com/vtraag/louvain-igraph https://pypi.org/project/louvain/ which installs into the "louvain" dist-packages directory. (from debc) ./usr/lib/python3/dist-packages/louvain/ I have it mostly packaged However currently in the Debian archive there's a different louvain package https://github.com/taynaud/python-louvain https://pypi.org/project/python-louvain/ https://salsa.debian.org/python-team/packages/python-louvain It installs into (according to debc) ./usr/lib/python3/dist-packages/community/ Unfortunately for this package we now automatically run autodep8 which fails because the import name is community and not louvain. autopkgtest [13:29:03]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import louvain; print(louvain)" ; done autopkgtest [13:29:03]: test autodep8-python3: [----------------------- Testing with python3.9: Traceback (most recent call last): File "<string>", line 1, in <module> ModuleNotFoundError: No module named 'louvain' autopkgtest [13:29:03]: test autodep8-python3: -----------------------] autopkgtest [13:29:03]: test autodep8-python3: - - - - - - - - - - results - - I think having a python3-louvain-igraph package which installs into louvain, while there is a separate python3-louvain package which installs into community is really confusing. I was wondering if the python3-louvain's binary package should be renamed to python3-community to match the python package name, and then the other louvain-igraph package could provide a bin package named python3-louvain which would match the package name. But this is clearly a thing that needs to be discussed. Diane
... I think this is something that the two upstream projects should discuss and come to an agreement on the right outcome, since the current set of names is confusing and overlapping. Perhaps the two projects will end up getting merged into one project, or one of them deprecated or one or both of them renamed. There are no reverse dependencies in Debian, but this is going to be tricky for users who previously installed python3-louvain.deb from python-louvain upstream and then after upgrading they suddenly get python3-louvain.deb from louvain-igraph with presumably an incompatible API etc.
From the perspective of pypi. One is "louvain" (which installs into "louvain" and one is "python- louvain", which installs into "community". If you're using pip you can easily install both of them if you want. Cleaning it up seemed hard. Currently the version python3-louvain in unstable based on python- louvain is 0.0+20181013git3fc1f575 and the current upstream version is 0.15. For the louvain igraph package their current version is 0.7.0. At the very least, the current python3-louvain package needs to be renamed to python3-community to meet python policy and to make the CI autodep8 import test work. So that seems like make a new release of python-louvain using the 0.0git convention with a transition package that depends on a new python3-community package. And then leave that alone for "a while". At some point then the new python3-louvain package based on the louvain igraph module could have a check in the maintainer script to tell the user to switch to python3-community if it's the older python-louvain version. Once the packages are renamed then the python-louvain version could switch from the 0.0git convetion to the pypi version. (Upstream didn't bother to put tags on github, so the only version numbers come from pypi). I have no idea how long the transition package should sit around for though. Diane
In the short term I recommend fixing this by adding a file to the Debian python-louvain package named "debian/tests/autopkgtest-pkg-python.conf" with the contents "import_name = community"
Thank you! I had a hunch there was an override option, but I couldn't find it. Diane
How about renaming the current python3-louvain package to python3-community-louvain using a normal transition package. (I got the new name from wRAR pointing out that upstream even suggests "import community as community_louvain") Then I can submit the other louvain package using a binary package name of python3-louvain-igraph. Eventually we can just drop the python3-louvain package in favor of the more specific names. Diane
+Steffen explicitly, given the team is not in Maintainer nor Uploaders that's incorrect: src:python-louvain builds a module called `community` (that includes also a cli tool), so the resulting binary package should either be `python3-community` or `community` where the cli is the main product and the module is installed in /usr/share/ to support it. this is incorrect too: (perspective) src:louvain (or src:louvain-igraph, as the upstream called their repo) builds a module called `louvain` so the resulting binary package should be `python3-louvain` eventually conflicting with the existing package (<< current-version-in-sid) src:python-louvain is in a pretty bad shape: it received a single upload in late 2018, it has an RC bug since a *day* after that upload, and it has never been in testing: tbh i dont consider this package to be maintained/targeting any stable release, so i believe you can "take over" the namespace given you seem to show interest in maintaining https://github.com/vtraag/louvain-igraph Regards,
It is bending policy, but I liked python3-community-louvain because the package name "python3-community" is just an exceptionally vague name. I think it's clearer if the name of the algorithm is in the package name. Also while looking through scanpy's louvain function I learned of yet more implementations of louvain. (Look through this function for different "flavors") https://github.com/theislab/scanpy/blob/550b82fdb53f35890e60343b826dd19454600bdb/scanpy/tools/_louvain.py#L23 Apparently what I'd previously called "igraph", scanpy calls "vtraag" because the vtraag version builds on the louvain implementation in python-igraph. There's also yet another version in nvidia's rapids library. I wasn't sure how much effort to put into saving the previous Debian louvain package since it didn't look like it was really usable by anyone. Libraries.io makes it look like the python-louvain "import community" version is a bit more popular and more actively developed. The "vtraag" version has a comment in it's REAME saying the developer deprecated it in favor of leidenalg (an improved method). On the other hand scanpy thinks the vtraag version is the most feature full implementation of louvain and uses it as their default. Diane