Re: Bug#982417: Python louvain packages naming confusion.
On Wed, 2021-02-10 at 18:35 -0500, Sandro Tosi wrote: > +Steffen explicitly, given the team is not in Maintainer nor > Uploaders > > > How about renaming the current python3-louvain package to > > python3-community-louvain using a normal transition package. > > 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. > 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. > > Then I can submit the other louvain package using a binary package > > name > > of python3-louvain-igraph. > > 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 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
Re: Python louvain packages naming confusion.
+Steffen explicitly, given the team is not in Maintainer nor Uploaders > How about renaming the current python3-louvain package to > python3-community-louvain using a normal transition package. 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. > Then I can submit the other louvain package using a binary package name > of python3-louvain-igraph. 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, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Python louvain packages naming confusion.
> > 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" > 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
Re: Bug#982417: Python louvain packages naming confusion.
On Wed, 2021-02-10 at 10:29 +0100, Michael R. Crusoe wrote: > > 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
Re: [Help] Re: metastudent-data breaks metastudent autopkgtest: 255
Whoops, I had a typo in that last command; if you go that route, please make it makeblastdb -dbtype prot -in "$<" -out "$(@:.psq=)" -blastdb_version 4 (I'd first try pushing forward, though.) Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: [Help] Re: metastudent-data breaks metastudent autopkgtest: 255
Control: tags -1 + upstream Andreas Tille writes: > Aaron (or whoever might want to check), do you have any idea? Due to metastudent-data's unwieldiness, I haven't tested thoroughly, but AFAICT the immediate, and with any luck only, problem is more fallout from the switch to BLASTDB version 5 format by default, which we can address in one of two ways: - Patch metastudent-data's build system to include more generated output in install-data-local. It should at minimum allow *.pdb in addition to *.phr, *.pin, and *.psq. Additionally allowing *.pot, *.ptf, and *.pto would cover the full range of current BLAST database components (though the files with those three extensions appear to be relatively specialized and perhaps not strictly necessary), and allowing all of *.p?? would make for best futureproofing. OR - Patch the build system to produce a legacy V4 database, which would ironically require cutting out the legacy formatdb wrapper, by changing the formatdb invocation to makeblastdb -dbtype prot -in "$<" -out "$(@:.psq=)" -blastb_version 4 Thanks for checking! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
[Help] Re: metastudent-data breaks metastudent autopkgtest: 255
Control: tags -1 help Aaron (or whoever might want to check), do you have any idea? Kind regards Andreas. -- http://fam-tille.de
Re: Python louvain packages naming confusion.
On Tue, 9 Feb 2021 at 23:53, Diane Trout wrote: > 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. > 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" -- Michael R. Crusoe
