[08:05] <rbasak> cjwatson: to correctly cache my LP objects, I should probably key the cache on the logged in user, to prevent private objects being available to the wrong logins. Unless I assume that there will only ever be one login in the app. Looking for something to key on, I found ._root, which looks like it gives me the top level Launchpad object which should be sufficient. But that's internal. Do you have any
[08:06] <rbasak> recommendation on this?
[08:23] <cjwatson> rbasak: I wouldn't cache across logins at all
[08:23] <cjwatson> rbasak: Why not just make the cache be per-process rather than persistent?
[08:24] <cjwatson> rbasak: And if you log out (unusual for an API-using program but OK), clear the cache then
[08:24] <rbasak> cjwatson: it is per-process and not persistent already. But it's quite deep inside an internal library, so I was concerned that I'd leave a subtle bug in that library unless I key the cache by login
[08:27] <cjwatson> rbasak: You could probably just key on the hash of the lp object itself.  Logging in is done by creating a new instance of that.
[08:27] <cjwatson> That is, instances of the Launchpad class
[08:28] <rbasak> I don't think that would work in this case.
[08:29] <rbasak> The problem is that the object is different, which is where my problem is coming from in the first place.
[08:29] <rbasak> I am iterating over source_package_publication_history objects
[08:29] <rbasak> On each of those, I fetch things like the distro_series attribute
[08:29] <rbasak> Each of those is resulting in an API round trip to fetch it (even if it comes back with Not Modified)
[08:30] <rbasak> However distro_series_link is the same every time, so that's what I'm keying my cache on (which works)
[08:30] <cjwatson> I don't see how you can both cache across logins and not cache across logins.
[08:30] <cjwatson> If the instance of the Launchpad object is different then surely that indicates a fresh login (if perhaps the same user)
[08:30] <cjwatson> So why is that happening?
[08:31] <rbasak> Each source_package_publication_history object is different, as expected, right?
[08:31] <rbasak> How do I get to the Launchpad object from that?
[08:31] <rbasak> I only found _root
[08:31] <rbasak> Which is internal
[08:31] <cjwatson> Oh I see what you mean
[08:31] <cjwatson> Meeting, back in 20 minutes or so
[08:31] <rbasak> ack
[08:47] <cjwatson> rbasak: I think using _root is your only option
[08:47] <cjwatson> It's technically private but in practice very stable
[08:57] <rbasak> OK. Thanks!
[08:59] <rbasak> FWIW, http://paste.ubuntu.com/p/rYnjwB5557/ is what I have now, which seems to work.
[09:03] <cjwatson> Looks quite nice
[09:05] <rbasak> Thanks!
[15:42] <ricotz> hi, afaics there are some ppa builds stuck at "purging the builddir" -- https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next/+build/16688179 -- most builds are stuck in https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next/+packages
[16:11] <ricotz> cjwatson, hi :), ^
[17:08] <tjaalton> are ppa builders all busy/taken?
[17:19] <tjaalton> oh, archive open.. maybe that's why
[18:25] <acheronuk> cjwatson: hi. is buildd-manager or something like that poorly again?
[18:43] <cjwatson> I'm not at home right now but I've requested a restart since it's probably that
[18:44] <acheronuk> ty