| wgrant | cjwatson: O | 08:27 |
|---|---|---|
| wgrant | Bah | 08:27 |
| wgrant | cjwatson: https://code.launchpad.net/~wgrant/turnip/no-buildout/+merge/252692 | 08:27 |
| wgrant | I've dropped buildout and hopefully made the non-buildout packaging a bit easier to use. | 08:27 |
| wgrant | setup_requires is approximately the worst thing in the world (it'll make setuptools talk to PyPI behind pip's back, even if you've disabled PyPI in pip), and the only way to work around that seems to be a ~/.pydistutils.cfg snippet. | 08:28 |
| wgrant | (we have a couple of our OpenStacky deps in LP patched to remove their setup_requires=['pbr'] for that reason) | 08:29 |
| wgrant | I swore not to get distracted by juju today. | 08:32 |
| wgrant | And instead got distracted by Python packaging. | 08:32 |
| wgrant | And didn't get anything actually finished. | 08:32 |
| blr | wgrant: hah, I'm not sure which of the two is more painful :) | 09:04 |
| cjwatson | wgrant: Have you tested that this works properly when doing "make deploy" in the charm from vivid? I'd been somewhat careful about not adding pygit2 to requirements.txt to avoid problems there. | 09:11 |
| blr | cjwatson: should be ok, libgit2-21 is in vivid? | 09:15 |
| cjwatson | Well, consider if vivid upgrades to a newer version; my point isn't so much what vivid happens to have today, it's being independent of the deployment system | 09:19 |
| cjwatson | If w has libgit2-27, I don't want to end up in a dilemma about what version of pygit2 we can use because some of us are on vivid and some on w, say | 09:20 |
| blr | cjwatson: perhaps we should just be following trunk | 09:20 |
| cjwatson | That isn't my point | 09:20 |
| blr | is there a workflow for automating packaging from github? | 09:20 |
| cjwatson | My point is to make sure that things work regardless of what libgit2, or none, is on the system you're deploying from | 09:21 |
| cjwatson | The strategy I had in place was to install python-pygit2 from the LP PPA in the unit, and virtualenv --system-site-packages to make use of it, so that we can control that precisely without having to deal with pip | 09:22 |
| cjwatson | I want to check that adding it to requirements.txt doesn't disturb that | 09:22 |
| cjwatson | (It may not, because wgrant also added version bounds that I don't think I tried) | 09:22 |
| blr | always a little reluctant to use --system-site-packages, but that does sound sensible. | 09:23 |
| cjwatson | I think it's less of a problem with immutable or mostly immutable units | 09:24 |
| cjwatson | Then again I come from a distro background, so ... | 09:24 |
| blr | no, I think that's fair. | 09:25 |
| cjwatson | Anyhow, if wgrant has finished up then I'll try the charm in a bit | 09:26 |
| blr | just as buildout was starting to grow on me... :) | 09:27 |
| blr | assuming there isn't anything too braindead in commit/log api branch, I'll spend tomorrow on deployment/mojo | 09:28 |
| blr | right, bedtime. night cjwatson | 09:31 |
| cjwatson | Night! | 09:32 |
| wgrant | cjwatson: Yeah, the charm was the bit I wasn't completely sure about. | 09:36 |
| wgrant | I suspect that if we want to use requirements.txt with a Debian pygit2 we may end up in trouble, unless we match the dep versions exactly (which can be seen in my diff). | 09:36 |
| wgrant | I'm not sure which is more ugly. | 09:37 |
| wgrant | system-site-packages, or being tied to a particular libgit2 | 09:37 |
| wgrant | Though in practice we're tied to a particular libgit2 anyway, since both it and pygit2 break API every release... | 09:37 |
| cjwatson | Right, well, the basic problem is that we can't install libgit2 from pip, so that's got to come from the system, and thus we have to go to special care to match it anyway | 09:39 |
| cjwatson | Let's see | 09:40 |
| cjwatson | wgrant: Nope | 09:42 |
| cjwatson | wgrant: http://paste.ubuntu.com/10584585/ | 09:42 |
| cjwatson | I deliberately don't have libgit2-dev installed here to make sure we don't have hidden dependencies on it | 09:42 |
| cjwatson | wgrant: Try pulling cffi, pycparser, pygit2 back out of requirements.txt? | 09:43 |
| cjwatson | I see https://twistedmatrix.com/trac/ticket/7795 is making progress, too ... | 09:46 |
| * cjwatson tries that | 09:48 | |
| cjwatson | wgrant: http://paste.ubuntu.com/10584612/ makes the charm work again. | 09:51 |
| cjwatson | wgrant: Perhaps a compromise would be moving that to pygit2-requirements.txt, so that you can still use pip for that for local development if you want to deal with the libgit2 issues? | 09:52 |
| cjwatson | blr: I think you could drop ['commit_time'] from format_commit in your commit-api branch. It exactly duplicates ['committer']['time'], and even though pygit2 has both there's no reason for us to. | 10:04 |
| wgrant | cjwatson: Sorry, distracted by real life. Let me see. | 10:05 |
| wgrant | Splitting those out into a separate requirements file might be sensible, indeed. | 10:06 |
| wgrant | cjwatson: The charm didn't whine about anything else? | 10:06 |
| wgrant | I'll test it properly before I merge, but need to set up a less tainted Juju VM. | 10:06 |
| wgrant | cjwatson: You're not unhappy with a --system-site-packages virtualenv for dev locally? | 10:07 |
| cjwatson | wgrant: No other whines. I'm fine with that kind of virtualenv for dev locally; the way I do it is to use a trusty lxc container that has the LP PPA enabled. | 10:28 |
| cjwatson | wgrant: Does https://code.launchpad.net/~cjwatson/launchpad/db-git-more/+merge/252672 look vaguely plausible? | 10:32 |
| cjwatson | Or did you want to see the matching code branch first? | 10:32 |
| wgrant | cjwatson: I wouldn't mind seeing the code. | 10:32 |
| cjwatson | Right, let me finish off the remaining possible tests today. | 10:33 |
| cjwatson | Oh, URL scheme for exported refs, that was the other thing I had to work out. | 10:34 |
| cjwatson | I think I'll just drop the exports and deal with that in a later branch. | 10:35 |
| wgrant | cjwatson: Yeah, variable-length paths ftl. | 10:36 |
| wgrant | cjwatson: Oh wow, just notced the Twisted ticket open in my browser. That is good news. | 11:11 |
| wgrant | Huh | 12:48 |
| wgrant | The turnip charm doesn't actually explicitly install git | 12:49 |
| wgrant | It was always there anyway when deploying from utopic and vivid to trusty, but not trusty to trusty... | 12:49 |
| === mgz is now known as mgz_ | ||
| cjwatson | wgrant: We'll have to work out some kind of URL scheme for refs, otherwise we can't usefully show summaries of branches. | 16:31 |
| cjwatson | wgrant: Strawman: filter to refs/heads/ only, and URL-encode the rest. | 16:33 |
| cjwatson | (We may need to show tags at some point, but that should be separate anyway.) | 16:33 |
| blr | cjwatson: thanks colin, yes commit_time is redundant, you're right. | 19:45 |
| blr | cjwatson: was there anything else that obviously needed addressing? | 21:17 |
| cjwatson | blr: I didn't quite get as far as actually running anything against it today, so I was just going on inspection. Didn't see anything else. | 21:18 |
| blr | cjwatson: ok, thanks. | 21:19 |
| cjwatson | Hopefully tomorrow, since I'm about to need to fill in the committer information in order to be able to progress with UI. | 21:19 |
| cjwatson | But my git-ref-scanner branch was big enough, and I wanted to start with something that only required today's lp:turnip... | 21:20 |
| wgrant | cjwatson: Well, traversing refs properly in a Zopey world isn't actually a problem. | 22:04 |
| wgrant | cjwatson: You can just have a traverser that consumes segments until it matches or can't match a ref. You don't even need a marker to indicate that traversal should stop, because a ref cannot be a prefix of another, as they're represented (ignoring packed-refs) as a directory tree. | 22:31 |
| wgrant | blr: Is your commit-api branch ready for review? | 22:32 |
| cjwatson | wgrant: oh, I thought you were vetoing variable-segment-length paths on principle | 23:00 |
| wgrant | cjwatson: Oh, no, that would be ugly and there's no need. | 23:01 |
| wgrant | If we were using stupid regex-based path matches we'd be in trouble, but luckily Zope is sane in respects like this. | 23:01 |
| cjwatson | github seems to strip off refs/heads/ | 23:01 |
| wgrant | cjwatson: I probed around to work out their rules at some point, let me see if I can find that piece of paper. | 23:01 |
| cjwatson | but they do permit multiple segments after that | 23:02 |
| wgrant | You can specify the full path, but they try stripping off refs/heads and refs/tags in that order. | 23:02 |
| wgrant | Which makes sense. | 23:02 |
| blr | wgrant: it is yep | 23:23 |
| wgrant | blr: Hm, I see that pygit2 decodes the message for us. Do you know how it does that? | 23:46 |
| wgrant | It's probably fine, but best to check. | 23:46 |
| blr | wgrant: didn't see anything explicit in the documentation, will have to look at the source. | 23:48 |
| wgrant | blr: libgit2 uses the encoding field in the commit message, but I wonder what it does on invalid UTF-8/ | 23:48 |
| blr | wgrant: perhaps need another latin-1 test for the commit body? | 23:49 |
| wgrant | blr: Indeed. Git commit messages are text, and they have an encoding field, so latin-1 can be coped with. But we should ensure we don't crash on cases where the message doesn't decode, as that's technically possible. | 23:49 |
| wgrant | Hm | 23:50 |
| wgrant | I'm making a whole lot of suggestions here that make a lot of sense if 0.22 changed the API.. | 23:50 |
| wgrant | Hm, no, these properties seem to exist in 0.21 | 23:51 |
| blr | tangential, but looking at the changelog, it might make sense to upgrade to 0.22 before working on clone. | 23:54 |
| wgrant | Indeed, it makes sense to track upstream as close as reasonably possible. | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!