[01:31] <blr> wgrant: afaict, the GitHostingClient is only called by the XmlRpcApi currently?
[01:38] <wgrant> blr: Yep, you can currently only create a repository by trying to push it.
[01:38] <wgrant> turnip makes the translatePath XML-RPC call. LP notices that it doesn't exist and creates it, calling back into turnip (while being called from turnip) to create the repository on disk before returning its path.
[01:55] <blr> wgrant: am I right in thinking GitRepository.destroySelf() only needs to call turnip from the api client?
[02:00] <blr> wgrant: are we preserving the model in the db, but setting a deleted flag?
[02:14] <wgrant> blr: At the moment we'll delete the LP database row too.
[02:14] <wgrant> blr: There's no reason to do complicated deferred deletion just yet.
[02:16] <wgrant> (LP has a history of not actually deleting things, which causes no end of trouble. We should design for proper deletion from the start here.)
[02:16] <blr> wgrant: ok, thanks
[02:44] <blr> wgrant: class StupidCache()
[02:48] <blr> also enjoyed the lolcat interfaces.
[02:50] <wgrant> Yup, StupidCache is the cache that remembers everything it's ever seen.
[18:54] <blr> cjwatson: thanks for the comments re UTF-8 filtering, agree that it makes sense to handle it there.
[18:56] <blr> cjwatson: the merge conflict was from providing a dependant branch on the MP, it doesn't exist in my local branch - how can I avoid that in the future?
[19:02] <blr> cjwatson: also noted the style for decorators in LP appears to be func_name_decorator, will amend that as well.
[20:37] <blr> cjwatson: wgrant: meeting today or tomorrow? (tomorrow in calendar, but we seem to have been shifting back a day recently)
[21:18] <cjwatson> blr: you know about the prerequisite branch facility in merge proposals?
[21:19] <cjwatson> Oh, wait, you are using that.  So then I don't understand why that requires you to have conflicts
[21:19] <cjwatson> blr: I doubt it has much to do with the dependent branch; it probably just means you need to merge lp:turnip into your branch, resolve conflicts, and push
[21:20] <blr> cjwatson: ok, that makes sense.
[21:36] <wgrant> Morning.
[21:37] <wgrant> cjwatson: Pre-reqs can in some circumstances confuse bzr merge into generating more conflicts, but I've only seen it rarelyt.
[21:37] <cjwatson> wgrant: Not on the underlay branch, surely?
[21:39] <wgrant> Ah, no.
[21:39] <wgrant> Misread that.
[22:08] <blr> cjwatson: would json.dumps(foo, encoding='utf8') be better than ensure_ascii=False?
[22:09] <cjwatson> encoding="utf-8" is the default
[22:09] <blr> ah so it is
[22:09] <wgrant> Anyone encoding JSON as anything else should be shot :)
[22:10] <cjwatson> The default escaping is just so that it works conveniently over file objects open in binary mode; I would *hope* cornice can cope with unicode, just haven't checked
[22:11] <wgrant> Hum
[22:11] <blr> cjwatson: yes it appears to
[22:12] <wgrant> encoding='utf8' isn't the default, is it?
[22:12] <wgrant> ensure_ascii=False leaves it as a unicode.
[22:12] <wgrant> (but cornice should know to encode that as UTF-8)
[22:12] <cjwatson> s'what https://docs.python.org/2/library/json says
[22:13] <cjwatson> probably encoding only takes effect if ensure_ascii=True
[22:13] <wgrant>     If ``ensure_ascii`` is false, all non-ASCII characters are not escaped, and
[22:13] <wgrant>     the return value may be a ``unicode`` instance. See ``dump`` for details.
[22:13] <wgrant> If ensure_ascii is true, they're escaped.
[22:13] <wgrant> Not encoded.
[22:14] <wgrant> I wonder if encoding= is only useful for charsets that don't match ASCII.
[22:14] <wgrant> I think encoding is meaningless with ensure_ascii=False, because it doesn't encode at all.
[22:14] <cjwatson> from a quick look at the code, I think it's actually used for decoding str objects you pass *in*
[22:14] <wgrant> Ah, that might make sense.
[22:15] <wgrant> It might also be relevant if eg. you use ensure_ascii=True and want EBCDIC output.
[22:15] <cjwatson> and if it's not 'utf-8' then it interposes a decoder
[22:15] <wgrant> No, that still doesn't work.
[22:15] <cjwatson> so encoding='utf8' is not actually quite the same as encoding='utf-8' here, potentially ... .encode and .decode have always hurt my brain
[22:15] <cjwatson> I'd leave encoding= well alone :)
[22:16] <cjwatson> I think if you want differently-encoded output you have to set the encoding on the file object and use json.dump(ensure_ascii=False), or use json.dumps(ensure_ascii=False).encode()
[22:17] <blr> tests pass with ensure_ascii=False at any rate
[22:17] <wgrant> Yep, ensure_ascii=False is usually the write way to go for web stuff, since HTTP can handle the charset itself.
[22:17] <cjwatson> That's probably only meaningful if you've specifically added tests with non-ASCII data.
[22:18] <cjwatson> At least in Python 2 where you get the "helpful" default of unicode->str working magically until something outside ASCII appears.
[22:19] <blr> so presumably I need a test with some latin1 data, or something of the sort
[22:19] <cjwatson> Right, I'd add one with ISO-8859-1 or something that's not valid UTF-8, and one with valid UTF-8.
[22:20] <cjwatson> And make sure that neither crashes, but that the former ref is silently omitted (so maybe have another valid UTF-8 ref in there as well or something)
[22:21] <blr> cjwatson: with the ref collection I can silently omit refs unable to encode, but I think we'll also want a validator on get() which returns a 400 perhaps?
[22:22] <wgrant> Are Pyramid's paths bytestrings or Unicode strings?
[22:22] <wgrant> LP's are pretty much treated as Unicode, so the ref wouldn't make it through the traversal logic.
[22:23] <wgrant> turnip-api should probably 404 if it fails to decode a path as UTF-8.
[22:23] <blr> wgrant: they're unicode
[22:24] <cjwatson> I think I would prefer 400 ("could not be understood by the server due to malformed syntax"), but either works.
[22:24] <cjwatson> Hopefully Pyramid already handles it ...
[22:25] <wgrant> Some frameworks do weird things, so we should probably check that.
[22:25] <blr> cjwatson: a test should confirm either way
[22:25] <blr> it would be nice not to need an explicit validator there.
[22:26] <cjwatson> http://docs.pylonsproject.org/projects/pyramid/en/1.5-branch/narr/views.html#handling-form-submissions-in-view-callables-unicode-and-character-set-issues has some stuff about this
[22:26] <cjwatson> But certainly we should check
[22:27] <cjwatson> Hm, that link is about form submissions rather than things like the path, though
[22:27] <blr> probably still applicable
[22:27] <cjwatson> maaaaybe
[22:27] <blr> heh
[22:28] <cjwatson> http://docs.pylonsproject.org/projects/pyramid/en/1.5-branch/narr/urldispatch.html "Note that values representing matched path segments will be url-unquoted and decoded from UTF-8 into Unicode within the matchdict."
[22:28] <wgrant> Yay, so it's sane.
[22:28] <wgrant> But I wonder what it does on failure.
[22:29] <blr> yes self.request.matchdict['ref'] is unicode
[22:29] <cjwatson> Yeah, can't immediately find that in the docs
[22:29] <wgrant> It's pretty modern and Zopey, so it's unlikely to be completely moronic.
[22:29] <wgrant> But it's not unheardof for frameworks to return a str if things don't decode properly...
[22:37] <cjwatson> Looks like it raises URLDecodeError, and you can register an exception view for that if you want custom behaviour.  Don't know what the default is.
[22:38] <wgrant> Right, it probably does something sensible then.
[22:39] <wgrant> cjwatson: So meeting in 24 hours?
[22:39] <cjwatson> And a bit, yeah.