Bug#982509: ITP: flask-basicauth -- HTTP basic access authentication for Flask
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-python@lists.debian.org Owner: Sandro Tosi * Package name: flask-basicauth Version : 0.2.0 Upstream Author : Janne Vanhala * URL : https://github.com/jpvanhal/flask-basicauth * License : BSD Programming Lang: Python Description : HTTP basic access authentication for Flask Binary package names: python3-flask-basicauth Flask-BasicAuth is a Flask extension that provides an easy way to protect certain views or your whole application with HTTP `basic access authentication`_. this is a dependency of locust
Bug#982508: ITP: locust -- Developer friendly load testing framework
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-python@lists.debian.org Owner: Sandro Tosi * Package name: locust Version : 1.4.3 Upstream Author : Carl Byström, Jonatan Heyman * URL : https://locust.io/ * License : MIT Programming Lang: Python Description : Developer friendly load testing framework Binary package names: python3-locust Locust is an easy to use, scriptable and scalable performance testing tool. You define the behaviour of your users in regular Python code, instead of using a clunky UI or domain specific language. This makes Locust infinitely expandable and very developer friendly. . Features: . * Write user test scenarios in plain-old Python -- If you want your users to loop, perform some conditional behaviour or do some calculations, you just use the regular programming constructs provided by Python. Locust runs every user inside its own greenlet (a lightweight process/coroutine). This enables you to write your tests like normal (blocking) Python code instead of having to use callbacks or some other mechanism. Because your scenarios are âjust pythonâ you can use your regular IDE, and version control your tests as regular code (as opposed to some other tools that use XML or binary formats). * Distributed & Scalable - supports hundreds of thousands of users -- Locust makes it easy to run load tests distributed over multiple machines. It is event-based (using gevent), which makes it possible for a single process to handle many thousands concurrent users. While there may be other tools that are capable of doing more requests per second on a given hardware, the low overhead of each Locust user makes it very suitable for testing highly concurrent workloads. * Web-based UI -- Locust has a user friendly web interface that shows the progress of your test in real-time. You can even change the load while the test is running. It can also be run without the UI, making it easy to use for CI/CD testing. * Can test any system -- Even though Locust primarily works with web sites/services, it can be used to test almost any system or protocol. Just write a client for what you want to test, or explore some created by the community.
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: 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
