Re: Python louvain packages naming confusion.
On Wed, 2021-02-10 at 01:49 +, Paul Wise wrote: > On Tue, Feb 9, 2021 at 10:21 PM Diane Trout wrote: > > > The fairly popular (in the world of bioinformatics) ScanPy package > > uses > > a Python version of the louvain clustering algorithm implemented > > by: > ... > > However currently in the Debian archive there's a different louvain > > package > > 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. >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. > > > 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. > > 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. > 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
Re: Python louvain packages naming confusion.
On Tue, Feb 9, 2021 at 10:21 PM Diane Trout wrote: > The fairly popular (in the world of bioinformatics) ScanPy package uses > a Python version of the louvain clustering algorithm implemented by: ... > However currently in the Debian archive there's a different louvain > package 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. > 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. 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. -- bye, pabs https://wiki.debian.org/PaulWise
Python louvain packages naming confusion.
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 "", line 1, in 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
Re: Bug#938076: python-pymetar: Python2 removal in sid/bullseye
On Sat, Feb 06, 2021 at 08:37:45PM +0100, gregor herrmann wrote: > > Find attached the full debdiff and the filtered debdiff with only the > > debian/* files. > > > > I tried to find a balance between doing all necessary changes and not > > completely overhauling the packaging. It seems that the resulting > > binary package works, both the commandline script and the module in > > ipython3, but as I'm not a python person I'd welcome reviews and > > suggestions for improvement. > > I don't feel confident uploading this NMU myself but I'd like to see > python-pymetar in bullseye. Very quickly looking at the filter diff for debian/*, that looks just fine. But it's too late for bullseye. Without an autopkgtest (which I'm not going to write myself not knowing the package), this will go over the 12th, and as such won't be due to the freeze policy. > Is this something the Debian Python Team could take over? I'll keep a tab open to review and sponsor the nmu (but anybody feel free to beat me). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: help me update dateparser to 1.0.0 in time for bullseye
On 2021-02-09 08:23:27, stefa...@debian.org wrote: > Hi Antoine (2021.02.08_16:53:57_+) >> I have more cycles for this again, and see the 1.0 release still hasn't >> hit unstable... need help? :) > > Uploaded. I suspect it might be too late for the freeze (in three days?) but we'll see, I guess. Thanks for your work in any case!! a. -- Le pouvoir n'est pas à conquérir, il est à détruire - Jean-François Brient, de la servitude moderne
Re: help me update dateparser to 1.0.0 in time for bullseye
Hi Antoine (2021.02.08_16:53:57_+) > I have more cycles for this again, and see the 1.0 release still hasn't > hit unstable... need help? :) Uploaded. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
