#musicbrainz-devel

nikki: but why would I do that?

geordi was basically undefined given how many things the eighty different people who had come up with "sort of ingestion" ideas had come up with, so I went for solving needs I understood

presumably because you want to know what's already matched?

which in this case was the two I mentioned, for editors and for data providers

I'm not good at explaining things, I know that :)

the ultimate goal I saw was adding things to MB automatically

and the rest being just tools to help with that

luks: why would you need an external database to keep track of it, if geordi knows what it has matched?

ah, yeah, that was not in the goals, and is a much harder thing to do right

we weren't sure we wanted to add stuff "automatically"; geordi is just a tool to make it easier to import/match large external data sources manually

versus making editing easier, which is the editor perspective on geordi

hawke_1: I need a database to know what's processed, possible not matched

but a bot could certainly ask geordi for unmatched releases, then either import or match them, then tell geordi that it's matched

and rinse, repeat

hawke_1: and I need to have a different app to be able to confirm "candidate" matches I'm not completely sure about

luks: Isn’t everything unmatched a candidate for matching?

I see what luks is saying, that doesn't let you keep track of things that you haven't successfully matched, yeah

hawke_1: possibly, but after some time

there's nothing in geordi for "I tried, but it didn't work, so don't try again for a bit"

adding support to geordi for storing 'potential' or 'possible' matches might be interesting

but yeah, failed matches would be an issue :/

yeah, indeed

I don‘t quite get what would be the “I” in “I tried but it didn’t work”

automatic matches are already displayed differently than human-done ones, but adding more levels may be a good idea

if geordi lets an app add arbitrary extra metadata fields, that might be interesting.

that would be any bot/algorithm wouldn’t it?

hawke_1: whatever script

yes

each one would need its own 'tried' flag

the app could add an 'x-luks-script-match: failed' tag or whatever

and do a search for things without that field?

well, geordi does let you keep track of who or what did the match, so

there's just no way to attach data to an item other than having direct elasticsearch access or submitting a match, which is what the potential-match thing would be for

also: apparently that pep8 test *did* in fact pass

which has me mystified.

ianmcorvidae: does it fail on your box?

kepstin-work: yes, rather dramatically

It might be an issue with the test code itself, then

failing to detect a failure :)

lol

(e.g. counting an 'unable to find executable' as a pass)

hah

I'm silly :P

hmm. by any chance, is jenkins running the tests from outside of the 'geordi' directory?

it's in a different geordi directory, yeah

Project geordi build #8: FAILURE in 4 min 17 sec: http://ci.musicbrainz.org/job/geordi/8/

Ian McEwen: Use the right directory for the pep8 test.

there you go, now it's failing properly :)

yup

FAILURE, Ian. It's a FAILURE!

yeah

(MBo failed too, when I added a PEP8 test. >_>)

I need to figure out which things it's yelling about I care about and which rules I should decree aren't part of geordi's style guide :P

(already removed one, for expecting two line breaks before classes (or maybe after imports? I wasn't really sure -- but double linebreaks are gross :P)

I agree.

Heh.

Excess whitespace makes me sad.

I want to adhere to Pocoo's style guide, so I'm keeping them.

hehe

Even as I generally disapprove of excessive whitespace.

I'm of two minds about maybe increasing the line length

I still think a consistent coding style is > removing whitespace.

ianmcorvidae: I've so far managed to keep all Python files under 80 characters long.

...

yeah, but as pep8 itself says, it's more important within a given project or file

>_>

hah

All *lines* in Python files.

insert joke here about writing python like APL? ;)

:)

Python forcing whitespace indentation is a pretty silly language to make small-yes-extensive one liner scripts in...

...

Ugh.

I'm too tired for this.

I should go to bed.

heh semicolons

Freso, consistent coding style is good. If I were working on a project that specified extra whitespace, I would probably do it. But for projects I start, I won't.

ianmcorvidae: "Remove Python-isms...": https://github.com/reosarevok/musicbrainz-serve...

haha

I use semicolons in python. :-P

ianmcorvidae: That's what happen when we juggle so many language in the MetaBrainz realm. :p

..

And I seriously can't write English tonight. Gee.

That's it.

The F's going to the bed.

Nighty night y'all.

nn

hehe

night Freso!

I'm considering using python for my scrobble-matching script. I don't know how I feel about that.

Not that that’s saying much

What sets it apart?

support for lots of formats, correct id3v2.4 writing

i'd use taglib, but I don't like C++ and the C api is incomplete

Fair enough. I only ever need vorbis comments, so I suppose it's not something I pay attention to.

yeah, if you're only dealing vorbis-style comments it's not too bad

I did use mutagen when I was working with id3v2.4, though. It was the only library that did it at the time.

Hmm. Any python users have a recommendation for a postgresql lib?

Leftmost: one that works :D

I have no idea which that is. :-P

psycopg2 is the usual recommendation

I mean, that's the low-level thing

if you want an ORM, sqlalchemy

ianmcorvidae: when you submit a release into musicbrainz geordi I don't suppose it submit acoustid/mbid pairings back to acoustic ?

ijabz: not at present, no

shall I raise an issue, would be really good if it did do this

ijabz: that’s been asked for…it needs some special access to do that without having the actual fingerprint data

yeah; it's been on my radar but if you'd like to file an actual issue for it to follow along with go ahead

but you have the acoustics don't you, yo don't need fingerprints

hawke_1: yeah, but luks was fine with it as long as it only submits things known to be acoustids, i.e., you can't just enter a random acoustid

ijabz: not for the existing APIs, they all require the fingerprint to be submitted

The acoustid api only reqires acoustic if thats what you mean

no, for submissions it requires a fingerprint

unless it's documented incorrectly

My understanding is also that you need the fingerprint.

i.e. you need to submit the AQ.... bit, you can't just submit <uuid acoustid> -> <mbid>

let me check my code

I've never used an ORM. Wonder if I should bother tryin.

trying

personally, I don't like them much, but

ianmcorvidae: oh your right, my bad

Fair enough. I'm certainly more used to doing it the low-level way.

fwiw, I try and stick to 80 char lines in haskell, but go over

I don't think I agree that failing to adhere to style should break the build