[16:04] <cjwatson> wgrant: bmp-webhooks fixed.  We do have to keep those fields in BMPDelta so that they're part of the snapshot in ObjectModifiedEvents, but I did all the rest of it as discussed.
[21:58] <wgrant> cjwatson: Hum, don't we have the entire new object in the OME?
[22:20] <cjwatson> wgrant: New yes, but the only old fields we have are those that are explicitly snapshotted by the delta
[22:21] <wgrant> cjwatson: Right, but if the fields can never change then why are the old copies necessary?
[22:21] <wgrant> Like we don't snapshot bug.id
[22:21] <wgrant> (Well OK maybe we do, but it wouldn't seem necessary)
[22:22] <cjwatson> er, oh, reasonable point
[22:23] <cjwatson> let me work out (not right now) why it failed tests without that
[22:23] <wgrant> Oh it actually failed tests?
[22:23] <wgrant> Odd
[22:23] <wgrant> That is certainly something that deserves investigation.
[22:23] <cjwatson> I think just because those fields were missing
[22:23] <wgrant> Oh, boring.
[22:24] <cjwatson> perhaps should special-case copying those fields from the new object so that webhook consumers don't need to hardcode the assumption that they won't change
[22:25] <cjwatson> it is conceivable that at some point we might allow changing prerequisites without resubmitting, for instance
[22:25] <wgrant> Indeed, it is possible.
[22:25] <wgrant> Not a terrible idea.
[22:26] <wgrant> But I still think that, until that time, that belongs in the event bits rather than the delta itself.
[22:27] <cjwatson> how do you mean?
[22:27] <cjwatson> outside the "old"/"new" elements of the payload, you mean?
[22:27] <wgrant> Oh, no, just what you suggested.
[22:27] <cjwatson> oh, ok
[22:28] <wgrant> The fact that they might change in future isn't good reason to keep them in the internal delta object to confuse us.
[22:28] <cjwatson> I'll do that tomorrow then, hopefully I won't get hideously sidetracked by another click vulnerability :P
[22:28] <wgrant> But it is probably good enough reason to include them in the payload generator.
[22:28] <wgrant> Heh, yeah.
[22:29] <cjwatson> I made a little progress on the turnip CI job today, though still a fair way to go.  But importantly I figured out the virtualenv construction bug I'd been stuck on
[22:29] <cjwatson> specifically that "find_links = /path/to/directory" in .pydistutils.cfg is *not* the same as "find_links = /path/to/directory/"
[22:29] <cjwatson> rsync disease
[22:30] <wgrant> I actually use a full file:// URL
[22:30] <wgrant> I don't remember why, but there must be a reason.
[22:30] <cjwatson> er, right, so do I
[22:30] <wgrant> Though it too has a trailing slash.
[22:30] <wgrant> Ah
[22:30] <cjwatson> but file:///path/to/directory != file:///path/to/directory/
[22:30] <wgrant> So probably the reason is that a raw path doesn't work, that'd do it.
[22:30] <wgrant> Yeah, odd.
[22:30] <cjwatson> the former stats the directory and then goes "oh, I clearly don't care about that"
[22:30] <cjwatson> thanks, setuptools
[22:31] <wgrant> ...
[22:31] <wgrant> Helpful.