| jelmer | lifeless: hi | 00:22 |
|---|---|---|
| poolie | hi igc, spiv, https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=udd | 00:55 |
| poolie | hi all | 00:55 |
| igc | hi | 00:59 |
| jml | poolie, hi | 01:01 |
| poolie | hi there jml! | 01:01 |
| jml | poolie, you should unify some accounts: https://www.ohloh.net/search?q=martin+pool | 01:01 |
| poolie | oh ok | 01:02 |
| poolie | i did a bunch of them the other week | 01:02 |
| poolie | jml, when was that stakeholder meeting going to be? | 01:02 |
| jml | poolie, 21 June, 1800UTC | 01:03 |
| poolie | ok | 01:03 |
| poolie | igc, spiv, https://edge.launchpad.net/bzr/+milestone/2.2.0 | 01:37 |
| poolie | https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=&orderby=-number_of_duplicates&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.importance:list=HIGH&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= | 01:51 |
| poolie | blah | 01:51 |
| poolie | which is high priority bugs by number of dupes | 01:52 |
| spm | new bug. LP needs shortly (cryptic) get request fields for sharing searches. Won't Somebody Think Of The IRC Channels!!!! | 01:53 |
| spm | shorter. even. | 01:53 |
| AfC1 | Why does the Ubuntu package "bzr" depend on "bzrtools". Shouldn't that be "recommends" or something? | 01:58 |
| === AfC1 is now known as AfC | ||
| jelmer | AfC: it doesn't depend on bzrtools | 02:00 |
| jelmer | AfC: it's in the Recommends in the original debian package and as far as I can tell that hasn't been changed in ubuntu | 02:01 |
| AfC | Oh. Have I done something wrong, then? I just did "apt-get install bzr" on a (very) fresh system and it dragged in bzrtools. I was a bit surprised by that | 02:01 |
| poolie | i think apt is configured to install recommends by default | 02:02 |
| jelmer | AfC: apt-get installs Recommends by default these days | 02:02 |
| poolie | there's a way to change this- | 02:02 |
| AfC | ew | 02:02 |
| poolie | jelmer do you think https://bugs.edge.launchpad.net/bzr/+bug/481748 is now ready to implement based on the list discussion about revision specs in urls? | 02:02 |
| ubot5 | Launchpad bug 481748 in bzr-builder "revspecs in recipes should be part of the URL (affected: 1, heat: 6)" [Low,Triaged] | 02:02 |
| poolie | hm | 02:04 |
| jelmer | poolie: yeah, I think so. Though that'll also need some generic work on supporting extra arguments in URLs | 02:04 |
| poolie | it's a bit hard to find | 02:04 |
| jelmer | AfC: aptitude -R will ignore recommends | 02:04 |
| jelmer | I'm not sure if -R will work for apt-get | 02:04 |
| AfC | jelmer: thanks, will try that | 02:09 |
| AfC | brb | 02:09 |
| lifeless | jelmer: hi? | 02:15 |
| lifeless | jelmer: I'm back off out in a minute, perhaps more content than ping, and I'll reply when I get back :) | 02:16 |
| poolie | afc, you can set something in /etc if you want this permanently | 02:17 |
| poolie | cheerio lifeless | 02:17 |
| lifeless | hi poolie | 06:00 |
| lifeless | poolie: I think I have the same hardware issue you had | 06:00 |
| poolie | hi there! | 06:01 |
| lifeless | loose cpu heatsink | 06:01 |
| poolie | ah, really? | 06:01 |
| lifeless | my games machine is powering off frequently | 06:01 |
| poolie | after yours was posted across the tasman? | 06:01 |
| lifeless | yes | 06:01 |
| lifeless | :( | 06:01 |
| poolie | erk | 06:01 |
| lifeless | it was -very- occasionally doing it first | 06:01 |
| lifeless | and I've inspected the CPU heatsink, and one corner screw is loosish | 06:01 |
| poolie | i'm still waiting for the 2GB DDR3 to come in so i can get it rebuilt | 06:01 |
| poolie | mm mine were too | 06:01 |
| lifeless | its a twist-lock thing | 06:01 |
| poolie | and i just kind of shrugged | 06:02 |
| poolie | right | 06:02 |
| lifeless | but that one won't lock firmly | 06:02 |
| poolie | exactly | 06:02 |
| lifeless | yeah | 06:02 |
| lifeless | I'm going to take a little time tomorrow | 06:02 |
| lifeless | and drop this in to get addressed | 06:02 |
| lifeless | also | 06:02 |
| poolie | heh i just found in my office the other day one of the special torx keys to tighten an ia64 heat sink | 06:02 |
| lifeless | we've put an offer in on a house | 06:02 |
| poolie | _that_ won't come loose :) | 06:02 |
| poolie | congrats | 06:02 |
| spiv | Ooh :) | 06:03 |
| lifeless | so I need to do a little run around dance for that with lawyers, inspectors etc | 06:03 |
| StevenK | lifeless: Nice! | 06:03 |
| poolie | mm | 06:03 |
| poolie | so we had a look here into https://bugs.edge.launchpad.net/bzr/+bug/582157 | 06:03 |
| ubot5 | Launchpad bug 582157 in Bazaar "pull from launchpad is slow (affected: 1, heat: 6)" [High,In progress] | 06:03 |
| poolie | without really reproducing it | 06:03 |
| lifeless | poolie: long story short - I'll be around on basically .au hours tomorow | 06:03 |
| poolie | istm there are two classes of problems here | 06:03 |
| poolie | ah you're not working so i won't bother you with it | 06:04 |
| lifeless | poolie: cool, thank you for pulling on the string | 06:04 |
| poolie | ok, np | 06:04 |
| lifeless | no, no bother | 06:04 |
| lifeless | its not like Canonical has traditional boundaries | 06:04 |
| poolie | ok so the two classes are: things where we know we're going slower than we should; and secondly things where we are unexpectedly slow | 06:04 |
| poolie | this bug would be in the second class | 06:04 |
| poolie | we have some ideas for shots in the dark that are probably useful anyhow, and for improving debuggability/supportability | 06:05 |
| lifeless | I can't wait for steams Linux port. | 06:05 |
| lifeless | one thing I thought of doing | 06:05 |
| lifeless | as a fairly immediately useful thing | 06:05 |
| poolie | after that, i'm going to put this back to incomplete | 06:05 |
| lifeless | was to make a per-invocation server side log | 06:05 |
| poolie | mm | 06:06 |
| poolie | so the ideas were | 06:06 |
| poolie | 1- use a socketpair to the ssh client, not a pipe | 06:06 |
| lifeless | that is, $ISO16whatever-$PID.log in ~/.local/bzr/ or some such | 06:06 |
| poolie | - not proven to fix this but a generally good idea; may alleviate poor blocking behaviour | 06:06 |
| poolie | ok | 06:06 |
| poolie | that's good too | 06:06 |
| lifeless | and then get that cherrypicked into LP production, add -Dhpss on the server side and get the logs synced every 5 minutes or so | 06:07 |
| poolie | 2- when TERM=spiv, server sends its hpss log over stderr so you can see on the client where it thinks it's spending time | 06:07 |
| lifeless | so we could see chunking, groupcompress stats etc | 06:07 |
| poolie | 3- log into that how much cpu time we spend per request | 06:07 |
| poolie | right | 06:07 |
| poolie | this would be quicker than getting it off lp via losas etc | 06:07 |
| lifeless | I like the idea of getting more data | 06:07 |
| lifeless | I think we should aim for getting more data all the time | 06:07 |
| poolie | 4- print a few more stats at the end: number of rpcs, number of ~mtu and <<mtu read() responses | 06:08 |
| lifeless | so that when someone says 'man it was slow this morning', we can see why | 06:08 |
| lifeless | that doesn't conflict with getting more in an immediate mode like you are describing | 06:08 |
| poolie | right | 06:08 |
| poolie | and i think that's it | 06:10 |
| lifeless | I agree that that bug should be used for 'lp is slower than bzr+ssh in general' | 06:10 |
| lifeless | I'm not sure where 'bzr+ssh around the world is slower than bzr+ssh locally' should go, if anywhere. | 06:11 |
| lifeless | [one theory about bzr+ssh performance is window choking on the tcp links - I was doing tcptrace analysis with spm a couple weeks back on this] | 06:11 |
| poolie | ah | 06:11 |
| poolie | that's possible | 06:11 |
| lifeless | on spm's recommendation I filed an RT ticket to increase the buffer limits on chokecherry or whatever the server is | 06:12 |
| poolie | crowberry? | 06:12 |
| lifeless | its in the lp queue if you want to dig it up | 06:12 |
| poolie | i wish the machine list page was up to date | 06:12 |
| lifeless | $suitablemachinename | 06:12 |
| poolie | and did you actually find anything from tcptrace? | 06:12 |
| poolie | i was just wondering if there was a machine like that | 06:12 |
| lifeless | was something a little suspicious, then PPing | 06:12 |
| lifeless | then looming | 06:12 |
| lifeless | that said, changing on crowberry live isn't the best place to test theories | 06:13 |
| poolie | using a socketpair may help there | 06:13 |
| poolie | right | 06:13 |
| lifeless | so we'll want to repurpose tungsten probably | 06:13 |
| lifeless | to be a testbed | 06:13 |
| poolie | something tcp related would be compatible with different people observing very different results | 06:13 |
| lifeless | I'm not sure why a socketpair would help | 06:13 |
| poolie | i think that they allow partial reads while a pipe does not | 06:14 |
| lifeless | interesting | 06:14 |
| poolie | imbw | 06:14 |
| poolie | oh the other possibility is that it's load-related on the server | 06:15 |
| lifeless | holy cow steam installs fast on SSD | 06:15 |
| lifeless | yes, load is a big concern | 06:15 |
| poolie | under windows? | 06:15 |
| lifeless | cedega | 06:15 |
| lifeless | more detailed logs would let us ascertain the concurrent bzr processes, and their activity, after the fact | 06:16 |
| StevenK | lifeless: What were your thoughts as bzr's TestCase as a fixture? | 06:33 |
| lifeless | *blink* | 06:33 |
| lifeless | StevenK: what do you mean | 06:36 |
| StevenK | lifeless: Context is your comment on this MP: https://code.edge.launchpad.net/~stevenk/launchpad/poppy-sftp-test-isolation/+merge/26717 | 06:38 |
| === radoe_ is now known as radoe | ||
| vila | hi all | 07:58 |
| spm | hey vila! | 08:03 |
| vila | spm: _o/ | 08:04 |
| thumper | what is the simplest way to get a time zone aware datetime object for the revision time? | 08:42 |
| thumper | a revision has a timestamp and timezone | 08:42 |
| thumper | is there a simple way? | 08:42 |
| vila | thumper: My memory may be a bit dusty, but I think I recall that the timezone and datetime should be supplied both or none of them | 08:45 |
| vila | thumper: so, short answer: no | 08:45 |
| thumper | is the timestamp of the revision in UTC or local time? | 08:47 |
| vila | gee, let me check, I'd say UTC, but I'm sure there are tests for that | 08:49 |
| vila | thumper: I was wrong, it's in local time (AFAICS) | 08:58 |
| thumper | vila: I think I'm going to agree with your first answer | 08:58 |
| thumper | vila: it is UTC | 08:58 |
| thumper | if I go: datetime.utcfromtimestamp(r.timestamp) it is right | 08:59 |
| thumper | where r is a revision object | 08:59 |
| vila | thumper: you checked that with a timezone != 0 ? | 08:59 |
| thumper | I'm not sure why a timezone is also recorded | 08:59 |
| thumper | r.timezone is 43200 | 08:59 |
| thumper | hang on | 09:00 |
| vila | it's a shame it's not better documented anyway :-/ | 09:01 |
| * thumper is a little frustrated | 09:02 | |
| thumper | it seems to be UTC | 09:02 |
| thumper | even though a timezone is recorded | 09:02 |
| vila | hmm, so I looked at the wrong place and we may have bugs there.. | 09:06 |
| vila | but looking at how log process that, yes, it seems to be UTC | 09:07 |
| sivang | hi | 09:56 |
| sivang | so, I have 2 branches who have diverged for some unclear reason. | 09:56 |
| sivang | nor merge or dif --old shows anythinig useful, | 09:56 |
| sivang | besides that my current branch is all extra to the push location - which was not like this before my laptop commit. | 09:57 |
| sivang | How to solve this? | 09:57 |
| jelmer | sivang: have you tried "bzr missing" ? | 10:03 |
| jelmer | that should tell you the revisions that are present in one branch but missing in the other | 10:03 |
| mwhudson | vila: when are you arriving in cambridge? | 10:07 |
| vila | mwhudson: tomorrow, around ~14h30 if all goes well | 10:08 |
| mwhudson | vila: ok | 10:08 |
| sivang | jelmer: I have, it suddenly shows me that all of the commits on the local branch I am working on are extras | 10:28 |
| parthm | mgz: thanks for the bzr-grep patches. i am going through no-match-fast path right now. | 10:30 |
| jelmer | sivang: that certainly explains why it's giving you that error | 10:41 |
| sivang | jelmer: right, but how is that that suddenly all those revision are extra? | 10:49 |
| sivang | jelmer: this wasn't so a day before. | 10:50 |
| sivang | jelmer: so it seems the only way to solve this is to rebranch | 10:55 |
| jelmer | sivang: Have you perhaps rebase your branch or something like that? | 10:57 |
| sivang | jelmer: not that I know of. | 11:01 |
| sivang | jelmer: This should be explicit enough for me to remember, from a bzr user POV | 11:01 |
| sivang | :) | 11:01 |
| sivang | jelmer: I'm rebranching, this takes too long to resolve with no apparent stuff to merg | 11:04 |
| sivang | jelmer: e.g. merge says there's nothing to do | 11:04 |
| C-S | ls | 12:55 |
| C-S | parthm: are you there? | 13:15 |
| parthm | C-S: hi | 13:28 |
| feckser | in .bzr/repository/indices I have many duplicate files. Can I unlink or hard link them all? | 14:16 |
| feckser | and not break anything? | 14:16 |
| maxb | feckser: This should not be the case | 15:16 |
| maxb | feckser: I suggest pastebinning the output of 'ls -lR .bzr/repository/' so people here can understand the situation better | 15:17 |
| feckser | maxb: what should not be the case? There should not be binary duplicate indices? | 15:21 |
| maxb | It's pretty unexpected, yes | 15:21 |
| feckser | http://www.pastey.net/137418-3kta | 15:31 |
| maxb | feckser: What? All your concern is about 4 60-byte files? | 15:54 |
| maxb | stop worrying | 15:54 |
| feckser | maxb: they obscure the duplicate list. | 15:54 |
| feckser | They make it harder to process removal of duplicates. | 15:55 |
| maxb | huh?! | 15:55 |
| feckser | When I perform a search for duplicates they are always returned. | 15:55 |
| maxb | So? Why does this bother you? | 15:55 |
| feckser | It makes the process of finding and removing unwanted duplicates harder | 15:56 |
| feckser | and that was only an example. There are more in other bzr repositories. | 15:57 |
| maxb | Unless you can find duplicates of substantial size, I feel this is a non-issue | 16:01 |
| feckser | maxb: it is not just about finding duplicates in bzr repositories, it is about finding them all my files. | 16:23 |
| feckser | some of the directories under ~ are bzr repositories. | 16:24 |
| maxb | Make your dupefinder ignore .bzr then | 16:24 |
| feckser | inore list | 16:24 |
| feckser | it has no ignore list | 16:24 |
| maxb | Personally, I see no problem with Bazaar happening to produce identical byte content in a few small files as an implementation detail | 16:26 |
| feckser | I did not say it was a Bazaar problem. I asked whether I can delete them without harm. | 16:26 |
| maxb | Answer: no | 16:26 |
| feckser | Can I hard link them without harm? | 16:27 |
| feckser | The duplicate finder (fdupes) smartly considers multiple links to same file as not duplicates. | 16:28 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| === beuno is now known as beuno-lunch | ||
| vila | feckser: don't ever hardlink these files, they contain the signatures (and appear to be empty in your case). If you start signing your commits... they won't be empty anymore | 18:01 |
| feckser | vila: so as long as I don't sign, they can be hard linked or removed? | 18:02 |
| vila | feckser: no, their presence is mandatory | 18:03 |
| feckser | vila: hard linked? | 18:03 |
| vila | feckser: if you hardlink them, you will be doomed the day someone in the project sign a commit | 18:03 |
| exarkun | it really sounds like you want fdupes to have an exclusions list :) | 18:03 |
| vila | feckser: besides, new ones will be created when the repo is repacked | 18:04 |
| === deryck is now known as deryck[lunch] | ||
| === IslandUsurperAFK is now known as IslandUsurper | ||
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| meoblast001 | hi | 18:55 |
| meoblast001 | i'm having more issues with obtaining the directory of a branch | 18:55 |
| meoblast001 | this result.branch.base isn't cutting it anymore | 18:56 |
| meoblast001 | because "filtered-154314860:///bzr/~mysticgalaxies/citrine-blender/" is not a file path | 18:56 |
| meoblast001 | at least not to me it isn't | 18:56 |
| meoblast001 | hm, a lot of stuff is undocumented | 18:57 |
| meoblast001 | i can't even find Branch.base in the docs | 18:57 |
| lifeless | meoblast001: branch.base is in the api docs | 21:09 |
| lifeless | pydoc bzrlib.branch | 21:09 |
| lifeless | ... | 21:09 |
| lifeless | :ivar base: ... | 21:09 |
| lifeless | meoblast001: that filtered: prefix is the soft chroot I was telling you about | 21:09 |
| lifeless | meoblast001: and why taking a suffix is needed, or unwrapping the filtering | 21:10 |
| lifeless | meoblast001: or, taking a config option from the branch (which I think is preferrable anyway) | 21:10 |
| lifeless | meoblast001: but you'll know what works best for your needs | 21:10 |
| meoblast001 | lifeless: oh, why wasn't it in these docs http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.BzrBranch7.html | 21:17 |
| meoblast001 | hm, those seem to be personal docs | 21:17 |
| meoblast001 | nvm | 21:17 |
| lifeless | http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.Branch.html | 21:18 |
| meoblast001 | ah | 21:18 |
| lifeless | looks like a bug in pydoctor | 21:19 |
| meoblast001 | config option? | 21:19 |
| lifeless | its showing inherited methods | 21:19 |
| lifeless | but not inherited variables | 21:19 |
| lifeless | attributes I mean | 21:19 |
| lifeless | meoblast001: config option - setting a key in branch.conf that you can look for | 21:19 |
| meoblast001 | lifeless: does Bazaar call plugins with .bzr as the working directory or is there something i need to use to set and get keys in branch.conf? | 21:21 |
| lifeless | branch.get_config() | 21:21 |
| meoblast001 | hm, undocumented | 21:21 |
| lifeless | its a decorator | 21:21 |
| meoblast001 | decorator? | 21:22 |
| lifeless | I think | 21:22 |
| lifeless | ah no, it is genuinely undoced, I'll fix | 21:22 |
| meoblast001 | lifeless: does that return a bzrlbi.config.Config? | 21:23 |
| meoblast001 | bzrlib* | 21:23 |
| lifeless | bzrlib.config.BranchConfig | 21:25 |
| lifeless | which has get_config, set_config etc apis | 21:25 |
| meoblast001 | lifeless: i seem to have a limited array of options | 21:27 |
| meoblast001 | i see no get_config or set_config | 21:27 |
| meoblast001 | i see get_user_option | 21:27 |
| meoblast001 | but not even a set_user_option | 21:27 |
| lifeless | http://people.canonical.com/~mwh/bzrlibapi/bzrlib.config.BranchConfig.html | 21:28 |
| lifeless | there is a set_user_option | 21:28 |
| lifeless | and get_user_option | 21:28 |
| meoblast001 | ah, at top | 21:29 |
| lifeless | as well as typed methods for email, signature checking, aliases and so on | 21:29 |
| meoblast001 | lifeless: so i want to use those, correct? | 21:29 |
| lifeless | in your plugin you want to use get_user_option | 21:29 |
| lifeless | you can just set the value in branch.conf with a text editor | 21:29 |
| meoblast001 | result.branch.get_config().get_user_option ('blahblahblah') | 21:29 |
| lifeless | yep | 21:30 |
| meoblast001 | since the return value of that get_config() is still sort of ambiguous | 21:30 |
| meoblast001 | ok, thanks | 21:30 |
| lifeless | generally speaking that will return None if the option isn't set | 21:31 |
| mgz | ah, a lifeless. | 21:41 |
| mgz | did you suggest I look at testrepository for my traceback matcher thing? | 21:41 |
| lifeless | yes | 21:42 |
| lifeless | testrepository.tests.matchers.MatchesException | 21:42 |
| lifeless | needs a little more suger | 21:42 |
| lifeless | sugar | 21:42 |
| mgz | will grab and look at. | 21:43 |
| mgz | hm, yeah, that's looking at exc_info | 21:44 |
| lifeless | possibly it should be built via composed subclass/equality style matches for each element of the tuple | 21:44 |
| mgz | which isn't a bad thing in general, but in this case we care about how the strings actually get passed through to the final stream | 21:44 |
| mgz | having something that takes an input of extract_tb style tuples might be okay though | 21:46 |
| meoblast001 | lifeless: ok, thanks... and i should have the config option set manually? | 21:48 |
| lifeless | yes | 21:48 |
| TresEquis | lifeless: how goes the househunt? | 21:50 |
| lifeless | great | 21:50 |
| TresEquis | cool | 21:51 |
| maxb | So, if you have a branch, stacked on another branch, and the base branch has been upgraded to 2a but the stacked one is still 1.x .... can you recover? | 22:57 |
| lifeless | yes | 22:58 |
| lifeless | upgrade the stacked one | 22:58 |
| james_w | lifeless: testr is pretty cool, thanks | 23:10 |
| lifeless | james_w: thanks! | 23:10 |
| lifeless | I'm glad you like it | 23:10 |
| james_w | lifeless: I'd prefer different output, like a big green light when all the tests pass | 23:11 |
| lifeless | james_w: I'd be delighted to incorporate patches | 23:12 |
| lifeless | if you wanted to include an arduino control module to drive a traffic light, we could even include that | 23:12 |
| james_w | heh | 23:12 |
| lifeless | did you see that? | 23:12 |
| james_w | I saw one that did lava lamps | 23:13 |
| james_w | I ported soupmatchers to use the discovery stuff today, makes for a pretty nice setup. | 23:13 |
| lifeless | awesome | 23:13 |
| lifeless | could you comment on the testtools bug about how that hangs together ? | 23:13 |
| james_w | I find the output on failure a little unpleasant, but can live with it | 23:14 |
| lifeless | or in some fashion write it up? That would be _most_ useful | 23:14 |
| james_w | sure | 23:14 |
| james_w | lifeless: if you could review the merge proposal that would be great | 23:15 |
| lifeless | which one ? | 23:17 |
| lifeless | bah | 23:17 |
| lifeless | which one ? | 23:17 |
| james_w | lifeless: https://code.edge.launchpad.net/~james-w/subunit/discovery/+merge/26893 | 23:19 |
| lifeless | thanks! | 23:19 |
| lifeless | I shall peruse | 23:19 |
| lifeless | james_w: ah, I see | 23:20 |
| james_w | lifeless: feel free to suggest alternative implementation strategies, it was more of an exploratory hack, but it works :-) | 23:21 |
| lifeless | so TestProgram can take the name of a callable | 23:21 |
| lifeless | or callables | 23:21 |
| lifeless | one way to do discover would be: | 23:22 |
| lifeless | make a series of callables, assign them to global names | 23:22 |
| lifeless | globals()[thunkN] = lambda:loader.discover(arg, pattern=options.discover_pattern) | 23:23 |
| lifeless | or something like that | 23:23 |
| lifeless | I don't think what you've done is all that ugly | 23:23 |
| lifeless | have a play, see what you think | 23:23 |
| lifeless | if you decide that the current stuff is better | 23:23 |
| lifeless | then lets ditch TestProgram entirely | 23:23 |
| lifeless | so that we don't have two different paths. | 23:24 |
| lifeless | ideally though, lets get a fixed TestProgram class in that file, which we can use appropriately, and submit a patch to python to make the stdlib one sufficient. | 23:24 |
| james_w | ah, you're saying that TestProgram should be able to take a list of callables, rather than it being a current feature? | 23:25 |
| lifeless | no | 23:31 |
| lifeless | it currently takes a list of names | 23:31 |
| lifeless | and does introspection | 23:31 |
| lifeless | see the testr.conf for testrepository, for instance | 23:32 |
| lifeless | (testrepository.tests.test_suite) | 23:32 |
| lifeless | oh bleh | 23:32 |
| lifeless | yes | 23:32 |
| lifeless | I'm saying that if we need to change TestProgram to accept callables as well as names | 23:32 |
| lifeless | or some such | 23:32 |
| lifeless | then we should | 23:32 |
| lifeless | or if we need to separate the concerns more | 23:32 |
| lifeless | then we should do that | 23:32 |
| lifeless | james_w: to put it most broadly: | 23:34 |
| lifeless | - subunit.run should be a trivial change to testtools.run | 23:34 |
| lifeless | - testtools.run should be a trivial wrapper for python's TestProgram | 23:35 |
| lifeless | so lets make things better up the stack, and where we have to wait for patches to be accepted / propogate to old versions etc, we should have a subclass that implements what our patch does, with a 'XXX: delete when python2.7 is the oldest version we support', or similar. | 23:35 |
| james_w | right | 23:37 |
| james_w | I don't see TestProgram taking a list of callables right now | 23:37 |
| lifeless | agreed | 23:37 |
| lifeless | it does take a list *of the names of callables* | 23:37 |
| james_w | right | 23:37 |
| james_w | but serialising the discovered tests back to that seems wrong | 23:38 |
| lifeless | so here's the review - please change subunit to use testtools more, it hasn't needed to for run as it was sufficient in the stdlib | 23:38 |
| lifeless | and do the discovery work in testtools | 23:38 |
| lifeless | and in testtools; either: | 23:38 |
| lifeless | - subclass TestProgram and make it more suitable | 23:38 |
| lifeless | - use a thunk to pass to TestProgram | 23:39 |
| lifeless | james_w: it wouldn't be serialising | 23:39 |
| lifeless | james_w: it would just call indirect the call to discover; I don't have a preference though | 23:39 |
| james_w | should we push --discover in to TestProgram? | 23:39 |
| lifeless | ultimately, yes. In fact 2.7 may do that already | 23:40 |
| lifeless | so it may be a 'copy from python' case | 23:40 |
| lifeless | as far as licencing goes | 23:40 |
| lifeless | testtools is license compatible with python, deliberately. | 23:40 |
| lifeless | so is subunit. | 23:40 |
| lifeless | just need to update the list of external copyright holders in the docs. | 23:40 |
| james_w | it doesn't yet, I was just checking that | 23:40 |
| james_w | oh, hang on | 23:41 |
| lifeless | I'm sure 2.7 supports discovery in some fashion | 23:41 |
| james_w | it does | 23:41 |
| lifeless | COPYING has the external copyright refs | 23:41 |
| james_w | but not --discover | 23:41 |
| james_w | it would be "python -m testtools.run discover" | 23:41 |
| lifeless | thats ... interesting | 23:45 |
| lifeless | uhm | 23:50 |
| lifeless | I don't have a strong opinion here, if it works +1. If its maintainable +1. If its the same as python has ended up upstream thats nice; if you think its nicer to be different, thats ok too. | 23:51 |
| lifeless | Just, where we are different, put patches forwardds. | 23:51 |
| lifeless | if you think we should try it differently, and decide later what is nicest, thats fine too - we can put a patch in once we are convinced one way or the other. | 23:51 |
| lifeless | back shortly, popping down to the bank. | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!