#metabrainz

GM all

LordSputnik: ping

justharshal: pong

LordSputnik: if one were adamant to run bookbrainz-ws, how would one go about doing that. (asking for a friend)

justharshal: It's quite difficult now... You'd need to either create your own database using bookbrainz-schema and populate it yourself or get hold of a really old database dump

Is it possible to get an old dump?

You can pretty much see the ws output formats anyway if you take a look at the bbws/structures.py file

LordSputnik: I was trying to better understand the existing webservice

LordSputnik: what would you suggest

I might have an old dump but I can't​ promise anything, will have a look for you today

LordSputnik: thanks

Is WolframAlpha not using MB data yet?

I've tried to run some queries based on https://www.wolframalpha.com/examples/Music.html but with people I know are in MB, but it doesn't recognise the names. (At first I thought it was hyphenation and Danish characters throwing it off, but even "rune barslund" or "baltic crossing" doesn't register.) Or do I need to feed it MBIDs directly?

Hm. Looks like it does use MB, but only for things that are also in WP, maybe? :|

zas: Morning :)

Perhaps make a plugin API version 1.9.9 that plugins can be ported to as we go, since the final 2.0.0 API is in flux?

And it seems WA doesn't even pick up all artists with a en:WP page...

Ugh, tests are failing because of py2.6 😐

Freso: didn't get that

samj1912: The 1.9.9 version thing?

yup

Right now if we port plugins/develop new plugins against the master/2.0 branch, there is a chance that the plugin API might be changed to be incompatible before final Picard 2.0 is released.

Freso: Yes - that is true, however I just think we should give users and plugin-authors a warning somewhere.

We shuld probably warn on the page that links to the daily builds that they are alpha quality.

My point is not the current status.

My point is that once Picard 2.0 is released, there might be plugin API 2.0.0 plugins in picard-plugins:2.0 that are actually made against an earlier and no longer compatible version of the 2.0.0 plugin API.

Yes - I get you. But I think we are over complicating things here.

I don't care that right now things may be broken.

EXACTLY.

But I do care that they're not when 2.0.0 is released. Which is why I think we should use another plugin API version for the 2.0 development.

The 2.0 API should be stabilised by the time we get to Beta - and in the mean time stuff is so fluid that people have to expect to change stuff.

Exactly.

What we have to decide is where the responsibility will lie for: a. Porting plugins over to Picard 2 and b. Maintaining them if the API then changes.

a. + b.: whomever feels like it.

An obvious example is that if we switch to WS/2 JSON, any plugins that process WS responses will need to change.

Ok.

Sounds good to me.

Sure.

Which is why it would be good to use a plugin API version like 1.9.9 now.

I am about to start migrating some of my plugins - I don't mind which, but I will need to know.

So if someone gets updated to Py3 and Qt5 but doesn't make the WS switch (or other changes that might come later), the plugin API will still reflect that it's not the final 2.0.0 API.

*somee

Sophist-UK: currently its my responsibility to port plugins to qt5/py3

**some

samj1912: gh:PP#79 is much better now

Build plugin files for specific api versions: https://github.com/metabrainz/picard-plugins/pu...

Happy for you to do most of mine - BUT I want to work on Title Case and Artist Abbreviation plugins - so if you could leave those until I have done so that would be good.

hehe :P

Back to work.

zas: https://github.com/metabrainz/picard-plugins/pu... ??

its the output path for the json file, didn't change that, it was named that way in the previous generate.py

Leo_Verto: Apparently I can't SSH from here. :( I have a fixed picard-plugins-v2-git PKGBUILD, but I can't push it until Friday or Saturday.

(By which time samj1912's gh:PP79 has likely been merged and I'll have to make more changes to it. :))

CatQuest: You should be able to just change it, no?

not afterit's closed.. https://tickets.metabrainz.org/browse/INST-419

INST-419: barbat

some of these string tambura things i'd liek to add a fix version too

Freso: I know, the log in cookie is borked

(or something :/)

CatQuest: weird, I can change the version after closing the ticket in picard

Did anyone file a ticket yet?

gimme a closed picard ticket to see if i can too?

Freso: about logins?

CatQuest: Yes.

CatQuest: PICARD-972

PICARD-972: Removing album with saves pending does not remove pending saves https://tickets.metabrainz.org/browse/PICARD-972

been a bit busy

hmm I can edit the fix version. yes... also the type and etc

do yo uhave ticket witouth a fix version that's closed?

Yeah, I can't edit the INST ticket either, and I have absolute privs. :/

zas: I saw a couple of posts that picard cant take multiple file loads anymore with 1.4.1

CatQuest: I don't think there's a better way right now other than reopening. I don't have time to look into it right now. Might be workflow related.

seems to be something about inst then.. look into admin prefs or something?

Freso: don't sweat it, check when you have time

samj1912: links?

and one more was in some jira ticket as a comment

ill have to find it

CatQuest: If you have the time, feel free to make an OTHER/Jira ticket about looking into it an assign it to me.

alright

also, maybe related: i can't edit my comments either

FWIW, I just loaded about 600 releases in picard just fine

I am on a SSD though

i didn't experienced this issue either

i *can* on picard tickets

(sorry Sophist, zas and samj1912 for testing there)

zas: is gh:PP#79 fine?

Build plugin files for specific api versions: https://github.com/metabrainz/picard-plugins/pu...

I didn't get your last comment

Yes, it is (fine), just wondering about renaming the out_path to a more explicit plugin_file_path

also, can you make generate.py executable (chmod +x), since it has a bang path

okay

We may change stuff on website to generate outside the git repo dir, now we can specify a dest dir

And adapt v1 end points to look at the same place as v2 using new directory structure

Freso: OTHER-294

OTHER-294: Can no longer edit fields on closed INST tickets https://tickets.metabrainz.org/browse/OTHER-294

zas: changed the mode

and also fixed a couple more things in test.py

I never ever like * imports

zas: any more reviews? if not, Ill make the changes to the corressponding PW and merge

*merge the PP PR I mean

weird. i can't put in enter in comments now :/