| gary_poster | bac benji frankban (gmb sprinting) hiya: https://plus.google.com/hangouts/_/4bd3b7cfd27f6147267f7436311fa84bc45f94b4?authuser=1&hl=en-US as soon as you can | 12:10 |
|---|---|---|
| benji | I'm back. | 13:33 |
| bac | hi gary_poster. i was reading jml's project start page and saw the note he had about their pre-commit pep8 checker. we're not decided we want such a thing but i thought it would be a nice exercise so i'm trying to add it to a branch of lpsetup. | 13:40 |
| gary_poster | +1 bac | 13:40 |
| bac | gary_poster: however it relies on pep8.py from pypi. i've tried cargo-culting some buildout stuff but cannot get pep8 to download | 13:40 |
| bac | might you have some tips? i've tried this: http://pastebin.ubuntu.com/1059070/ | 13:41 |
| gary_poster | bac, the buildout stuff in lpsetup is a nasty decoy | 13:41 |
| bac | i hoped, adding in a versions.cfg with pep8 in it would do the magic. it does not | 13:41 |
| bac | ho | 13:41 |
| bac | oh | 13:41 |
| gary_poster | bac, it should be removed (right frankban?) | 13:41 |
| frankban | gary_poster, bac: indeed. | 13:41 |
| bac | gary_poster: if it is removed, how would you suggest i proceed? | 13:42 |
| gary_poster | frankban, if bac wants to add a dependency, he should add it to setup.py and then...? | 13:42 |
| gary_poster | use a virtualenv aiui | 13:42 |
| gary_poster | and then...? :-) | 13:42 |
| gary_poster | we should write this up, in a HACKING or in a page linked to by HACKING. Moreover, it may be that buildout is the Preferred Technology for this (notice capitalization) and we'll have to conform | 13:43 |
| gary_poster | But for now... | 13:43 |
| frankban | gary_poster, bac: never used, but I've found this project: http://pypi.python.org/pypi/tissue/0.3 | 13:45 |
| gary_poster | frankban, oh, should not go off on a new tech for this | 13:45 |
| gary_poster | if at all possible | 13:46 |
| gary_poster | I hoped/assumed there would be instructions like thisL | 13:46 |
| gary_poster | : | 13:46 |
| gary_poster | 1) add to setup.py | 13:46 |
| gary_poster | Scratch that, trying again | 13:46 |
| gary_poster | 1) setup virtualenv | 13:46 |
| gary_poster | 2) get lpsetup | 13:46 |
| gary_poster | 3) add dependency to setup.py | 13:46 |
| gary_poster | 4) run python setup.py build | 13:47 |
| gary_poster | or some other similar tool | 13:47 |
| gary_poster | frankban, oh I see what you mean, now that I actually looked at project. So...that's something else we need to know how to do | 13:48 |
| gary_poster | bac, do they have a custom pre-commit pep 8 checker, or are they using some standard? | 13:48 |
| gary_poster | must be a standard of sorts since also getting it from pypi | 13:48 |
| gary_poster | http://pypi.python.org/pypi/pep8/ | 13:49 |
| gary_poster | and tissue is actually ay 0.7 | 13:49 |
| gary_poster | at | 13:49 |
| gary_poster | http://pypi.python.org/pypi/tissue | 13:49 |
| gary_poster | and uses pep8.py | 13:50 |
| bac | gary_poster: jml refers to http://bazaar.launchpad.net/~canonical-ca-hackers/ubuntu-webcatalog/trunk/view/head:/src/webcatalog/tests/test_pep8.py | 13:50 |
| gary_poster | oh :-( | 13:50 |
| gary_poster | oh | 13:50 |
| gary_poster | so that's just a separate test | 13:51 |
| benji | does pocketlint do pep8 checking? | 13:51 |
| gary_poster | so another approach | 13:51 |
| gary_poster | benji, it does not advertise pep8 explicitly, and it does not use the apparently "standard" pep8.py if its setup.py is to be believed | 13:53 |
| gary_poster | bac, I think we are supposed to want pip, and I think we are about to fall off the cliff of "python packaging sucks" | 13:56 |
| benji | hmm | 13:57 |
| bac | gary_poster: so wanting to add one dependency cause use to go off the cliff? | 13:57 |
| bac | s/cause us/ causes us | 13:57 |
| bac | ergh, can't even type my corrections properly | 13:57 |
| gary_poster | bac, you got it, because if we are trying to do it "right" that means we have to define what "right" means. Although, if pep8 is packaged in debian we can look the other way...checking | 13:58 |
| benji | I for one don't want pip. :) As far as I have seen, it is inferior to buildout for the use cases I care about | 13:58 |
| gary_poster | bac, pep8 is packaged in debian. | 13:59 |
| gary_poster | quick, jump on that plane, and run away! | 13:59 |
| gary_poster | benji, buildout is dying. Jim and /me killed it, unintentionally. He didn't want to maintain it, and I went off in a direction no one wanted, and it's been in an essentially broken state for...years now? Meanwhile, the self-proclaimed and generally appreciated "python packaging experts" have declared virtualenv (going into Python as you know) and pip as The Standard. See for instance the bottom of http://pack | 14:01 |
| gary_poster | ages.python.org/distribute/ . | 14:01 |
| gary_poster | Meanwhile, at Canonical, noone wants to actually pay attention. They want system python and deb packages to be the standard for us | 14:02 |
| benji | Yeah, I have accepted it as inevitable that buildout will never be popular. I still think it is often the best tool for the job, even if we have to use different tools for political reasons. | 14:04 |
| gary_poster | essentially broken: my evidence is that there are three trunks. We use 1.5.x. Others use 1.4.x. jim uses 2.alpha.x | 14:04 |
| gary_poster | fair enough, my argument had 0% content about "best tool for the job" except insofar as swimming along with the stream is generally better unless you are in the business of making streams. | 14:05 |
| gary_poster | bac, can you make setup.py declaration plus deb dependency work for you? | 14:06 |
| bac | gary_poster: geez, it is 'pep8' not 'python-pep8' so i didn't see it. | 14:06 |
| gary_poster | yeah I got tripped up by that too, sorry, should have mentioned | 14:06 |
| bac | gary_poster: perhaps. i'm looking at it now. | 14:07 |
| gary_poster | apparenty nose and testtools are somewhat in competition, apparently | 14:07 |
| gary_poster | that's bad because nose wins in any popularity contest | 14:08 |
| benji | I like that: "[S]wimming along with the stream is generally better unless you are in the business of making streams." | 14:08 |
| gary_poster | :-) | 14:08 |
| gary_poster | oh look, someone-probably-Robert broke sourcedeps.conf by adding extraneous newlines. joy. | 14:11 |
| frankban | gary_poster: if we want to switch to pip+virtualenv then we have to distribute shelltoolbox on pypi. tissue is broken and doesn't work with the last pep8. :-/ | 14:12 |
| gary_poster | frankban, good to know, and that confirms my desire to not add new untrusted dependencies. We can add pep8 with debian, and add the test as a standalone test the way bac said jml is doing it: http://bazaar.launchpad.net/~canonical-ca-hackers/ubuntu-webcatalog/trunk/view/head:/src/webcatalog/tests/test_pep8.py | 14:13 |
| gary_poster | I kind of prefer the tissue approach actually | 14:13 |
| frankban | gary_poster: however the lpsetup code broke some pep8 rules we usually break in our launchpad guidelines: e.g. "E123 closing bracket does not match indentation of opening bracket's line". but you can setup pep8 to ignore some rules... | 14:13 |
| gary_poster | but I don't want to add another low-popularity dependency if we can help it | 14:14 |
| gary_poster | ack | 14:14 |
| gary_poster | I will not be surprised if people in Canonical point to lxc instead of virtualenv for package development and testing. | 14:17 |
| gary_poster | For Ubuntu packages, that makes some sense | 14:17 |
| gary_poster | lxc and debs rather than virtulenv and eggs, I mean | 14:17 |
| bac | gary_poster: i'm a bit confused about how to specify debian packages in setup.py and i find the docs less than helpful. can you shed some light? | 14:26 |
| frankban | bac: you can't afaik. | 14:38 |
| bac | on call | 14:38 |
| gary_poster | bac, correct, you cannot. This would be a machine or lxc setup. The setup.py assertion would just be for politeness, and maybe for pip if you did it right. | 14:39 |
| bac | gary_poster: diogo's tarmac & jenkins work runs in the QA lab. access is available only via openvpn. i need to request the QA lab admin to generate openvpn certificates via an rt. i suspect all of yellow needs access. | 14:58 |
| gary_poster | bac, all of LP needs access | 15:01 |
| gary_poster | we need it now | 15:01 |
| gary_poster | but we will be handing over maintenance to the team as a whole | 15:01 |
| bac | gary_poster: would you like to reply to that RT requesting access for everyone or do that later? i'd prefer not to be too broad if it is going to delay getting yellow access in place. | 15:03 |
| gary_poster | bac, understood. Two thoughts so far. | 15:05 |
| gary_poster | First, if we have a constrained initial set, it should include Robert and Francis and Diogo and Matthew just in case | 15:05 |
| bac | diogo and matthew already have access | 15:06 |
| bac | as does francis | 15:06 |
| bac | here is the initial RT for access: https://rt.admin.canonical.com//Ticket/Display.html?id=53196 | 15:06 |
| gary_poster | Second, we should make it clear what our long term request is, IMO. In other words, we could say "eventually, we would like all Launchpad maintainers to have access. However, initally, only the yellow squad needs access now. | 15:07 |
| gary_poster | OK | 15:07 |
| gary_poster | Will go look | 15:07 |
| gary_poster | bac, that's resolved--looks like we should have a new RT? | 15:08 |
| bac | gary_poster: i filed a new rt and cc yellow on it 8 minutes ago | 15:09 |
| gary_poster | oh.. | 15:09 |
| gary_poster | have not received | 15:09 |
| bac | at least i intended to cc yellow. let me forward. | 15:09 |
| gary_poster | k | 15:09 |
| bac | brb | 15:10 |
| gary_poster | k | 15:10 |
| gary_poster | bac, do you have permission to see https://rt.admin.canonical.com//Ticket/Display.html?id=53930 ? | 15:23 |
| bac | gary_poster: i do not. troubling. | 15:23 |
| gary_poster | bac, apparently using "yellow" as rt CC is not a good idea. We should do it individually | 15:23 |
| gary_poster | (the one I asked you to look at is the one I filed) | 15:24 |
| bac | gary_poster: but i filed it. i would think i could read | 15:24 |
| gary_poster | bac, yours is https://rt.admin.canonical.com//Ticket/Display.html?id=53963 | 15:24 |
| gary_poster | I can't see it | 15:24 |
| gary_poster | but I expect you can | 15:24 |
| gary_poster | I am going to ask flacoste to clear it up in RT for those two tickets | 15:24 |
| bac | gary_poster: oh, right, i can see the old one: https://rt.admin.canonical.com//Ticket/Display.html?id=53930 | 15:24 |
| bac | logged in as warthogs | 15:25 |
| bac | gary_poster: but i cannot see the new one i just filed | 15:25 |
| gary_poster | oh | 15:25 |
| gary_poster | huh | 15:25 |
| gary_poster | I am logged in through openid bac | 15:25 |
| gary_poster | bac, I bet you could see the one you filed if you logged in via your openid | 15:26 |
| bac | gary_poster: hangout for a sec? | 15:26 |
| gary_poster | sure | 15:26 |
| gary_poster | you doing it, or shall I | 15:26 |
| gmb | HALLO. | 15:40 |
| gmb | Or | 15:40 |
| gary_poster | HALLO | 15:41 |
| gmb | Goedemiddag | 15:41 |
| gary_poster | heh | 15:41 |
| gmb | gary_poster, re: goals: I haven't been able to get into CA. I will ping the admin team about it. | 15:42 |
| gary_poster | gmb: cool, lemme know if I should get involved | 15:45 |
| gmb | Ok | 15:45 |
| frankban | benji: do you have a minute? | 15:46 |
| benji | frankban: sure | 15:46 |
| frankban | benji: hangout? https://plus.google.com/hangouts/_/1c0ef54f3bef4cfa99dfeced5fb3af2621bbb66a?authuser=0&hl=it | 15:47 |
| gmb | gary_poster, FWIW, jam tells me that both he and Francis have been having problems with HRa, and dragnob is aware of it and dealing with it. | 15:49 |
| gary_poster | ok cool gmb thanks for heads up | 15:49 |
| bac | gary_poster: https://portal.admin.canonical.com/53963 | 16:09 |
| gary_poster | bac, I just noticed myself, thx :-) | 16:10 |
| gary_poster | frankban, I should create a different card for subcommand smoke tests, right? What you are doing now is similar, but different? Or should we really regard these as smoke tests? | 16:57 |
| frankban | gary_poster: I am writing tests for expected steps and handlers for each subcommand | 16:58 |
| gary_poster | I know. :-) | 16:58 |
| gary_poster | Is your point, you don't know whether we should we call them smoke tests or not, but they are good to have? | 16:59 |
| frankban | yes gary_poster :-), and I am a bit confused about what kind of smoke tests you were thinking about | 17:00 |
| gary_poster | frankban, I'm inclined to say that what you are doing now plus some simple "does the --help option work for all commands" test is a good start. what kind of smoke tests: I'd like us to be confident that each command can be called (initialized). The --help does that. What you are doing is a bit more sophisticated. I'd say it lets us be confident that each command seems to do broadly what we expect, to the degr | 17:03 |
| gary_poster | ee that the names of the steps clarify that. | 17:03 |
| benji | they seem more like non-smoke tests to me. My definition of a smoke test (which was I did not just totally make up while typing this line) is that a smoke test just tells you that nothing went wrong and if something does go wrong, it tells you nothing about what in particular it was | 17:03 |
| gary_poster | However, unless I misunderstand, it does not let us know whether the command will work at all. | 17:05 |
| gary_poster | benji, my understanding was that a smoke test was less about only giving a small amount of information as to a failure, but about whether roughly things seem to be working at all. Maybe I'm completely off base. | 17:06 |
| gary_poster | For me, the --help is a smoke test because if it fails, we know things are not hooked up well enough for the command to run at all. | 17:07 |
| gary_poster | Given the tests frankban is adding, I'd feel comfortable even simply checking whether the return code was 0 | 17:07 |
| benji | gary_poster: right (the bit about being helpful is only a corrolary: "real" tests should point you in a direction, smoke tests are under no such burden) | 17:07 |
| gary_poster | cool | 17:08 |
| benji | (agreed on the --help bit; it is a smoke test, and -- I think -- a good one) | 17:08 |
| gary_poster | cool. so benji, frankban, I'll add a card to add tests that verify that "lpsetup COMMAND --help" returns with a 0 for all commands. If you disagree or have a better idea, lemme know. :-) | 17:09 |
| benji | +1 | 17:09 |
| benji | if we had a --dry-run switch for all commands, that would be a good smoke test too (to help show import errors, name errors, missing command-line parameter processing, etc.) but it's too much work to add just for a smoke test (real tests would probably be less work and more valuable) | 17:10 |
| frankban | gary_poster: +1, with the -h option you test that the command is correctly registered to the parser, and that the arguments make sense (no clashes, basically), so it adds value. | 17:11 |
| gary_poster | cool, thanks guys | 17:14 |
| bac | gary_poster: how do you get virtualenv to handle dependencies that are only available as debian packages, e.g. python-shelltoolbox? | 17:51 |
| gary_poster | bac, option 1 is you tell virtualenv to allow all the system packages through. See --system-site-packages | 17:52 |
| gary_poster | bac, option 2 is to get the source for python-shelltoolbox and use it. pip seems like it has the option to specify bzr branches, for instance | 17:53 |
| bac | gary_poster: ok, option 2 implies pip-ing which i wasn't sure i was going to do | 17:54 |
| gary_poster | right | 17:54 |
| gary_poster | I assumed option 1, bac, I must admit. | 17:54 |
| benji | if anyone wants to review an lpsetup branch (we really should canonicalize its name, we have "lpsetup" in some places and "lp-setup" in others) I would appreciate it: https://code.launchpad.net/~benji/lpsetup/add-get-subcommand/+merge/111904 | 17:56 |
| benji | bac: is there anything I can do to help with tarmac? | 18:55 |
| bac | benji: i don't think so | 18:56 |
| benji | k | 18:56 |
| bac | benji: i'll review your lpsetup branch. when it is approved please don't merge it. let me see if i can get a manual run of tarmac to do it | 19:02 |
| benji | bac: k | 19:02 |
| bac | benji: approved. please make the changes, pushed, and set the MP to approved and then i'll try running tarmac | 19:15 |
| benji | bac: will do | 19:15 |
| benji | bac: the MP is ready for you | 19:25 |
| bac | cool | 19:25 |
| bac | benji: Merging lp:~benji/lpsetup/add-get-subcommand into lp:lpsetup failed: Unapproved changes made after approval | 19:36 |
| benji | bac: you are technically correct, the best kind of correct (so says tarmac) | 19:36 |
| benji | bac: I guess you should add another approve=code comment | 19:37 |
| bac | i marked the whole MP. let's see if that works | 19:37 |
| benji | bac: I had already marked the MP as approved | 19:37 |
| bac | benji: before or after you pushed the post-review changes? | 19:38 |
| benji | bac: after | 19:38 |
| bac | weird. it now correctly notes r34 is the approved version | 19:38 |
| benji | bac: hmm, but the page says that 33 was the approved revision; I wonder if firefox and bzr were in a race and I lost | 19:39 |
| bac | it says 34 now | 19:39 |
| bac | on the MP page | 19:39 |
| benji | I see that 34 is the approved revi... right | 19:39 |
| bac | benji: so tarmac happily merged your changes...into a local branch on my machine. that's not so helpful | 19:43 |
| benji | :) | 19:44 |
| bac | so am i supposed to manually do a 'bzr push' after tarmac does its thing? i thought that was the whole point | 19:45 |
| bac | i hate projects that have docs that are a little too clever...and then don't actually do what is advertised | 19:46 |
| bac | benji: so on my second try it actually merged your branch | 20:18 |
| benji | idempotent | 20:19 |
| bac | benji: it is weird. there is tree_dir settting, that lets you set where you want the local copy of the project's trunk to be | 20:24 |
| bac | with tree_dir = /var/cache/lpsetup | 20:25 |
| bac | it only merged locally. i later found an example that made more sense so i changed to | 20:25 |
| bac | tree_dir = /var/cache/tarmac/lpsetup/trunk | 20:25 |
| bac | with that setting it actually did the landing. odd. | 20:26 |
| benji | yeah, I don't understand that | 20:27 |
| gary_poster | bac, reviewed https://code.launchpad.net/~bac/lpsetup/sansbuildout/+merge/111942 . I started crying a little bit, but then managed to hold it in. | 21:45 |
| bac | gary_poster: it'll be ok | 21:54 |
| bac | gary_poster: yay, merged by tarmac with nosetests run as pre-commit hook: https://code.launchpad.net/~canonical-launchpad-branches/lpsetup/trunk | 21:57 |
| bac | [bug=] is kind of gross but not easily solved | 21:57 |
| gary_poster | bac, yay! | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!