[04:55:16] <wm-bot>	 !log tools.poty-stuff <legoktm> Updated from 3de1ef1 to 86ed8c8
[04:55:22] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.poty-stuff/SAL
[15:25:31] <legoktm>	 fyi https://github.com/legoktm/toolforge/pull/20#issuecomment-1488831766
[15:26:51] <Lucas_WMDE>	 hm. not entirely surprising I guess
[15:26:58] <Lucas_WMDE>	 will ponder some more when I’m not on working time :)
[15:27:20] * Lucas_WMDE isn’t a member of the toolforge rust cabal… yet
[19:49:26] <legoktm>	 yeah, the Python one is pretty...basic and low maintenance tbh, it hasn't seen any real changes since like early 2021
[19:51:04] <legoktm>	 I am very happy with how https://gitlab.wikimedia.org/repos/mwbot-rs/toolforge/-/blob/main/src/pool.rs has turned out, it pretty seamlessly lets you maximize concurrency and connection reuse within Toolforge connection limits all without the user needing to know or care that different databases are on different servers, etc.
[19:53:38] <legoktm>	 (not that any of my tools come anywhere close to getting the amount of traffic that this is optimizing for, but it's the thought that counts!)
[19:54:47] <dancy>	 Seems like the pool_s1..s15 stuff should be some kind of map.
[19:57:42] <legoktm>	 it used to be, the downside was that if you wanted to lazily insert s2 into the map, you'd need a write lock on the map, which would then block reads on s1, s3, etc. Hardcoding them as separate variables means there's no central lock to limit things
[19:57:50] <legoktm>	 https://phabricator.wikimedia.org/T325951#8490906 is where I explored this
[19:59:16] <legoktm>	 I think there probably is some better middle ground, in which the map uses a lock that handles concurrent read/write access against individual keys but I didn't immediately find anything like that when I last looked into it
[20:00:03] <dancy>	 Nod.
[20:00:07] <legoktm>	 (and maybe my hardcoding is offensive enough that it will nerd-snipe someone into making it better? ;-))
[20:00:28] <wm-bb>	 <lucaswerkmeister> I was thinking that the Python mwapi library could maybe also use some more attention (from the same hypothetical group of developers that would take over toolforge?)
[20:00:30] <wm-bb>	 <lucaswerkmeister> but it turns out that library had a release last year that I totally missed, so, maybe it’s still fine
[20:12:17] <bd808>	 legoktm: I would be happy to help keep the python `toolforge` library functioning if you are ready for co-maintainers. If you are looking for a new home for it, we could put it somewhere  under https://gitlab.wikimedia.org/repos/cloud/toolforge or https://gitlab.wikimedia.org/toolforge-repos.
[20:13:29] <bd808>	 Maybe making a Toolforge tool account for it (python-toolforge?) would be reasonable? That would give a logical git repo name and also a shared maintainers email address for anywhere that would be handy.
[20:19:00] <wm-bb>	 <lucaswerkmeister> interesting idea
[20:19:13] <wm-bb>	 <lucaswerkmeister> I think I’d advocate against actually putting the Python code in such a tool though
[20:19:50] <wm-bb>	 <lucaswerkmeister> lest we get another `magnustools`, and other tools linking against `/data/project/toolforge-python` (instead of putting it in their venv) in a way that makes those tools harder to develop outside toolforge
[20:27:27] <bd808>	 @lucaswerkmeister: I would agree that loading the library from the tool somehow would be a bad idea. Mostly I just like Toolforge tool accounts as a hook for group collaboration.
[20:27:50] <wm-bb>	 <lucaswerkmeister> yeah, that part sounds good
[20:28:08] <wm-bb>	 <lucaswerkmeister> I wonder if we could even put PyPI credentials in a chmod 600 file in the tool’s home
[20:52:59] <bd808>	 @lucaswerkmeister: maybe. Typically pypi creds are bound to humans with co-maintainership via registration at pypi (much like Toolforge really). We could figure out how to automate most of the publishing cycle though for sure. It should be possible to have a "publish on tag" workflow via either GitLab or GitHub automation.
[20:53:16] <wm-bb>	 <lucaswerkmeister> also sounds good
[20:53:27] <wm-bb>	 <lucaswerkmeister> (I know next to nothing about PyPI, in case it wasn’t obvious ^^)
[20:53:31] <wm-bb>	 <lucaswerkmeister> (also left a reply on github btw)
[20:53:39] <legoktm>	 bd808: both you and Lucas are already collaborators on the GH repo, and I've added you as a PyPI owner (Lucas, let me know your username!). please feel free to take whatever action y'all feel is appropriate
[20:53:59] <bd808>	 sneaky legoktm ;)
[20:55:17] <wm-bb>	 <lucaswerkmeister> oh my :D
[20:55:26] <wm-bb>	 <lucaswerkmeister> I probably don’t have a PyPI account but let me see if I can add one
[20:57:36] <wm-bb>	 <lucaswerkmeister> alright, I’m lucaswerkmeister now
[20:58:33] <legoktm>	 invite sent :)
[21:01:16] <wm-bb>	 <lucaswerkmeister> 2FA added
[21:03:31] <bd808>	 PyPi had Google send me these fancy titan hardware keys for my PyPi account, but I never have gotten around to figuring out how to use them.
[21:04:17] <legoktm>	 fwiw I don't think it should be a big burden to take care of, but tbh I honestly forgot that repo even existed and that is a good enough sign that I'm not currently maintaining it and given that I'm not even developing tools in Python anymore, I don't really want to maintain it either
[21:05:09] <bd808>	 passing it on to others is a reasonable thing. it is handy and several of my tools use it
[21:07:45] <wm-bb>	 <lucaswerkmeister> makes sense, yeah
[21:11:24] <bd808>	 T333495
[21:11:25] <stashbot>	 T333495: Setup proper Wikimedia home for https://github.com/legoktm/toolforge - https://phabricator.wikimedia.org/T333495
[21:39:00] <Platonides>	 somewhere in gitlab.wikimedia.org is probably a better cared home, I gues
[21:39:25] * Platonides wonders if he ever created an account on gitlab.wm.o
[21:39:44] <bd808>	 Platonides: https://gitlab.wikimedia.org/toolforge-repos/python-toolforge will be the place "soon"
[21:43:45] <Platonides>	 ok, it seems I do have a gitlab account :D