alastairp: reosarevok: yvanzo: on a quick look here https://github.com/metabrainz/musicbrainz-server/… , I do not see an index on email id column. as we want to access the email using username from LB often, should we add one ?
2021-05-03 12352, 2021
alastairp
_lucifer: what kind of query do you mean?
2021-05-03 12308, 2021
alastairp
editor.id will be a primary key, which means that by default it'll have an index
2021-05-03 12321, 2021
_lucifer
ah yes. that's musicbrainz_row_id in BU?
2021-05-03 12306, 2021
alastairp
maybe
2021-05-03 12311, 2021
dhhruv joined the channel
2021-05-03 12317, 2021
alastairp
what are you trying to do? Are you reading this table in SQL from somewhere?
2021-05-03 12340, 2021
_lucifer
yes, we need to access the editor table to get the email during login.
2021-05-03 12346, 2021
zas
Hey dhhruv
2021-05-03 12352, 2021
zas
outsidecontext: ^^
2021-05-03 12356, 2021
dhhruv
Heyy
2021-05-03 12324, 2021
zas
we read your proposal, and we find it rather thin, it lacks of details
2021-05-03 12338, 2021
zas
did you explore the current related Picard code?
2021-05-03 12300, 2021
outsidecontext
hi dhhruv
2021-05-03 12307, 2021
dhhruv
Not much really, because I was caught up in other projects.
2021-05-03 12331, 2021
dhhruv
hii outsidecontext
2021-05-03 12304, 2021
zas
what's your exact experience with Pillow? you say you used it in your projects, are those available online?
2021-05-03 12356, 2021
dhhruv
Yes, I used pillow in my Project Pixxia, it is available on GitHub. Also, I used it in my friend's Project for some ups and downs but that one may not be available.
2021-05-03 12335, 2021
dhhruv
I may have some and I'm ready to read and learn more from the docs if needed. I'm good at getting info out of documentation.
2021-05-03 12331, 2021
_lucifer
alastairp, https://github.com/metabrainz/listenbrainz-server… after the user completes auth on MB side, we reach here. I intend to fetch the email from the editor table here and perform the checks on it.
2021-05-03 12314, 2021
zas
dhhruv: what's the biggest Python project you worked on for now?
2021-05-03 12343, 2021
alastairp
_lucifer: right, but lines 27-34 are reading from an HTTP request. lines 35-39 are adding to the local LB database. Nothing here touches the musicbrainz database
2021-05-03 12328, 2021
_lucifer
alastairp, yes. the logic to fetch email from mb db needs to be added here.
2021-05-03 12348, 2021
alastairp
_lucifer: this data should come from the musicbrainz oauth request
zas YouTua is my biggest project till now and am still working on it. It is available on GitHub.
2021-05-03 12359, 2021
_lucifer
alastairp: ^^ this is the data present in the oauth request data sent by mb
2021-05-03 12320, 2021
alastairp
_lucifer: hrm. OK, my mistake - I kind of just assumed it would be there. Which makes sense why we didn't store it locally
2021-05-03 12304, 2021
_lucifer
it probably makes sense because we might not want to share the user's email with external apps.
2021-05-03 12320, 2021
alastairp
my personal preference would be that we ask MB to add this to the API response. But this might require a bit more development work (e.g. ideally we'd have a scope to request it, and then users could choose to share it or not)
2021-05-03 12324, 2021
zas
dhhruv: did you use MB Picard already?
2021-05-03 12301, 2021
alastairp
_lucifer: sorry, my entire discussion today was based on the assumption that this data was there, so I guess that's why we were confused many times
2021-05-03 12349, 2021
dhhruv
zas Nope. But I'm gonna see as soon as my exams are over. Stuck on that since 15-20 days.
2021-05-03 12357, 2021
_lucifer
ah! makes sense. we were on entirely different pages. no worries :)
2021-05-03 12304, 2021
alastairp
we do have config.MB_DATABASE_URI, but that's currently only used in the labs api at the moment
2021-05-03 12325, 2021
_lucifer
we fetch email directly in listens importer so that's not an issue.
OK, changes a bunch of my assumptions. 1) a database query is pretty fast, I'm not opposed to even doing this any time we need to check a user's email address. 2) if we did want to copy in the email address or a flag, this is much easier (just a few sql queries, instead of an individual http request for each user),
2021-05-03 12327, 2021
alastairp
3) given that we're planning on making auth changes soon, we probably shouldn't request that MB add all of this additional functionality to share email addresses
2021-05-03 12337, 2021
_lucifer
if the query is fast, then let's go with 1.
2021-05-03 12349, 2021
alastairp
4) if we want to get the email address from the MB database in the login provider then this is fine, just do exactly what the spotify importer does
2021-05-03 12345, 2021
alastairp
one difficulty here is that these are separate database servers, so there may be some additional overhead. by adding email to the LB users table, we get it for "free" because we have to look up the user information on every page load anyway
2021-05-03 12359, 2021
_lucifer
yeah, makes sense.
2021-05-03 12316, 2021
outsidecontext
dhhruv: about the proposal: Currently this mainly lists our requirements. I think what we had been looking for was some idea, how you would go about implementing this and what you would tackle first and what parts of Picard need to be updated for this. Without some deeper knowledge about Picard this if of course difficult, but can you give some rough overview how you would go about this?
2021-05-03 12339, 2021
alastairp
_lucifer: thanks for stepping me through this!
2021-05-03 12357, 2021
sumedh joined the channel
2021-05-03 12303, 2021
dhhruv
outsidecontext As said earlier, due to university exams, my supervisor's pressure to to lead new projects at the summit and family emergency (going on right now), I'm not able to take a look at the Picard Repository so I haven't worked out everything on a flowchart yet but I've used Pillow in mine as well as other projects so it looked familiar.
2021-05-03 12341, 2021
reosarevok
I'm releasing prod, btw (re: alerts)
2021-05-03 12341, 2021
outsidecontext
dhhruv: Ok, I understand. Unfortunately this is a bit thin for a proposal. We would like to have been able to do this project with you, but at this point there is too much uncertainty for us to mentor this project.
dhhruv: as is, it is likely your proposal will be dismissed, mainly because at this point you should have explored the related project a bit more and it results your proposal is too thin. Though I encourage you to get involved in MetaBrainz projects, because contributing, even outside GSoC, is a good thing. If you want to get involved into Picard, just select few tickets to work on, and open pull requests.
2021-05-03 12342, 2021
outsidecontext
dhhruv: I'd be happy if you'd decide to maybe stay around and maybe decide to contribute to the project in some way. We always need some help here :) If you decide to apply again for next year that'd be great also, just remember to add some more details to your next proposal.
outsidecontext and zas I understand that you'd like to mentor a person who has already been working on Picard or has a proper plan for working or has explored the code. I applied in Picard because things working on here looked a bit familiar but unfortunately the time I thought I'd be giving to explore Picard was taken out by the family situation
2021-05-03 12311, 2021
dhhruv
right now. Anyways, I was going to work out the code whether or not I get selected in GSoC.
2021-05-03 12333, 2021
dhhruv
Will reach out on this channel once I've done progress on this. Thank you again outsidecontext and zas for reaching out to me. Looking forward for the mentorship outside GSoC.
2021-05-03 12339, 2021
outsidecontext
dhhruv: honestly, that would be great. Thanks for your proposal. I think in this case there was simply not enough time for both you and us to get in touch more. Also my best wishes for the personal issues you are dealing with.
2021-05-03 12350, 2021
dhhruv
Thanks outsidecontext
2021-05-03 12333, 2021
zas
dhhruv: yes, please hang around, good luck for your exams.
ruaok: alastairp: we will reject listens from users with associated email after Nov 1. but do we allow users without email to login or not at that time?
2021-05-03 12307, 2021
alastairp
yes, login is fine (because then we need to show them a banner)
2021-05-03 12348, 2021
_lucifer
we can show the banner without logging them in though. when the user tries to log in, we'll perform the check and show the banner. the actual login happens after that.
2021-05-03 12356, 2021
shivam-kapila
Does the email need to be associate only with listens?
2021-05-03 12302, 2021
shivam-kapila
Associated*
2021-05-03 12331, 2021
shivam-kapila
Listen submission I mean. Sorry for being unclear
2021-05-03 12313, 2021
_lucifer
i think that's the plan for time being.
2021-05-03 12350, 2021
shivam-kapila
In that case I tend towards allowing login. We wont need an email in case the user wants to visit the feed or wipe listen history and so on
2021-05-03 12349, 2021
_lucifer
yeah, that makes sense. thanks!
2021-05-03 12342, 2021
ruaok
Yes to allowing logins.
2021-05-03 12305, 2021
shivam-kapila
_lucifer: what was the bug in the app. I just updated and wanna test it
2021-05-03 12339, 2021
_lucifer
shivam-kapila: the tagger would fail with Document Provider not found.
2021-05-03 12353, 2021
_lucifer
that should not happen now (hopefully)
2021-05-03 12316, 2021
shivam-kapila
The tagger just shows the headbang emoji for me
2021-05-03 12342, 2021
_lucifer
😞, that could be the other bug discovered just before doing the release. I was hoping that it wouldn't be triggered often but seems that is not the case...
_lucifer: right, but I think that's a bit of an annoying move on our part. we should allow people access to their data even if they haven't set an email address
2021-05-03 12308, 2021
_lucifer
alastairp, yeah i agree. i had forgotten about that aspect.
alastairp, thanks to you as well for the help and the work
2021-05-03 12314, 2021
akshaaatt[m]
<_lucifer "😞, that could be the other bug "> Hi, what's this bug about? I could have a look at it.
2021-05-03 12352, 2021
_lucifer
akshaaatt[m]: thanks. its the same issue i mentioned before the request failed or returned no results. since we do not propogate errors in TaggerRepository to UI, the UI is left hanging at loading screen.
2021-05-03 12332, 2021
akshaaatt[m]
Oh okay. We can deal with this.
2021-05-03 12327, 2021
_lucifer
another thing is we currently do not use file name to as fallback for the track name so the chances of match reduce.
