[mayhem](https://matrix.to/#/@mayhem:chatbrainz.org): iirc you were running into issues with python's GIL in the early stages of building the new LB mapper, right? if so, python 3.14 just dropped and [now officially supports free-threading, i.e., GIL-free](https://docs.python.org/3/whatsnew/3.14…
2025-10-08 28138, 2025
Toasty joined the channel
2025-10-08 28147, 2025
mayhem[m]
yeah, there is only one teeeny little problem they don't talk about... all the libraries that your python project depends on, they too need to be free-running enabled. and for the massive number of libs I need for this project, not going to happen anytime soon.
2025-10-08 28117, 2025
yvanzo[m]
bitmap, reosarevok: Hi!
2025-10-08 28143, 2025
bitmap[m]
hello
2025-10-08 28134, 2025
reosarevok[m]
Hi!
2025-10-08 28154, 2025
yvanzo[m]
I saw you updated a PR about having different test DBs.
2025-10-08 28121, 2025
bitmap[m]
MTCaptcha was successfully deployed to beta yesterday
2025-10-08 28133, 2025
yvanzo[m]
That reminded me of the issue we do have with DBDefs for different use cases.
2025-10-08 28139, 2025
bitmap[m]
yep, I spent quite a bit of time rebasing and fixing test failures in a few PRs
We also did forget we had to update the beta DBDefs for Russian and MTCaptcha, but we did that soon after release and just rereleased :)
2025-10-08 28123, 2025
yvanzo[m]
But it is difficult to use and keep up-to-date for mirrors that have local settings.
2025-10-08 28149, 2025
yvanzo[m]
Similarly, it is difficult to use and keep up-to-date for development setup that have local settings.
2025-10-08 28130, 2025
yvanzo[m]
It would be great to come with default settings for the most common use cases.
2025-10-08 28146, 2025
yvanzo[m]
We currently have only one file DBDefs/Default.pm.
2025-10-08 28127, 2025
yvanzo[m]
I don’t have an exact plan for how to implement it, but here is one proposition: Have alternative FooDefault.pm and allow selecting the initial set of default settings through environment/options.
2025-10-08 28114, 2025
yvanzo[m]
(It would still allow overwriting some settings through a local DBDefs.pm.)
2025-10-08 28114, 2025
bitmap[m]
that is probably the most logical way to do it with our current system. but it would be ideal to switch to a different config file format in the future which would allow for rewriting the config automatically
2025-10-08 28142, 2025
yvanzo[m]
Yes but that wouldn’t be deployable quickly as it would be a breaking change and would take much more time too.
2025-10-08 28107, 2025
bitmap[m]
anyway having separate defaults files for common environments makes sense to me
2025-10-08 28159, 2025
bitmap[m]
at least with them being in perl you can use extends to only override what's necessary
Okay, just to conclude the first topic, I can try to implement it for mirrors, and then we can look together about doing the same for other use cases (test-database, tests, development…)
2025-10-08 28103, 2025
reosarevok[m]
If you're up for that, I don't see why not
2025-10-08 28102, 2025
bitmap[m]
reosarevok[m]: the request to return the browsed events in the response deserves some discussion, perhaps we can do that on the ticket for now though
2025-10-08 28126, 2025
reosarevok[m]
Oh, ok, so I was wondering if I was getting it right
2025-10-08 28157, 2025
reosarevok[m]
So their point is that if you have an event MBID from whatever source they want to be able to get that event and related ones in one go?
2025-10-08 28100, 2025
reosarevok[m]
That seems sensible to me
2025-10-08 28139, 2025
bitmap[m]
yes but it's essentially implementing MBS-6459 too, which I'm not sure makes sense via the browse endpoint. maybe it does, but we are already breaking the definition of "browse"
Like, it makes some sense that browsing events by event would load all the events related to that event, and it's hard to argue that the event itself is not related to it :)
2025-10-08 28149, 2025
bitmap[m]
per the WS documentation: "Browse requests are a direct lookup of all the entities directly linked to another entity ("directly linked" here meaning it does not include entities linked by a relationship)."
2025-10-08 28109, 2025
reosarevok[m]
I mean, events are not directly linked anyway so that's already not true, right
2025-10-08 28118, 2025
reosarevok[m]
So, there's two things here: it seems useful to get an event and all related events recursively, and it seems useful to get multiple events in one API call
2025-10-08 28139, 2025
bitmap[m]
that's my point, the current implementation is already at odds with the original design intention of the web service (although there was already another browse endpoint that used relationships IIRC)
2025-10-08 28113, 2025
reosarevok[m]
I mean, I think that was thought out before we realized that for example recordings are unrelated to works entirely unless we use rels :)
2025-10-08 28119, 2025
reosarevok[m]
(and so are artists)
2025-10-08 28140, 2025
reosarevok[m]
So if we strictly followed that browse would seem to be pretty useless for several use cases
2025-10-08 28119, 2025
reosarevok[m]
I suspect the "directly linked" thing is actually not obvious to anyone really?
2025-10-08 28141, 2025
reosarevok[m]
I think most people see relationship links and the area for an artist or whatnot as basically the same thing 🤷♂️