Team Chat Logs

February 26, 2010

2010 1
Mo Tu We Th Fr Sa Su
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
<< <   > >>

[05:14:04.756354]<Hodgestar>osimons: pylint 0.19 uses exit codes 1-31 as a bit mask to return which types of warnings have been detected. While I think this is broken (since pylint has obviously completed its task successfully) I wondering whether we should do anything about it for Bitten?
[05:14:14.254954]<Hodgestar>davidfraser: ^^^
[05:16:29.975376]<osimons>Hodgestar: i think that is what i found too - noted on some ticket? can't quite remember. however, is it an error or is it not? it is kind of like unittests failing if you are keen on lint - with onerror="ignore" as the usual handling i suppose? no firm opinion from me.
[05:18:44.124770]<Hodgestar>I did a search for pylint and didn't find anything.
[05:19:43.856299]*asmodai pats osimons
[05:20:02.021705]<osimons>asmodai!!!!!
[05:20:07.624713]<Hodgestar>I have onerror="ignore" but I don't really consider the build a failure if there are some pylint warnings.
[05:20:08.788011]<asmodai>Hey dude.
[05:20:24.103521]<Hodgestar>In the same way I don't consider not having >= 100% coverage a build failure.
[05:20:46.287784]<osimons>asmodai: how's the ice skating - do they now know how the exchange between inner and outer turns is supposed to happen?
[05:21:34.185169]<osimons>come back, Hodgestar!
[05:21:50.787945]<osimons>don't leave us! pleeeeease!
[05:23:11.298566]<osimons>the norwegians know how to do the switch - they are just very precuations and take their time to make sure it is correct. That is the main reason why they are so slow...
[05:24:03.770323]<osimons>what's up asmodai - all's well? not made it for pycon i guess?
[05:29:48.950035]<asmodai>osimons: Oh har har har
[05:29:58.726415]<asmodai>osimons: It was the coach's fault :(
[05:30:42.392111]<asmodai>osimons: And no, I tend to avoid conferences. Did watch some of the videos this week.
[05:31:36.297598]<Hodgestar>Blerg. Laptop suffering from weird HPET failure.
[05:36:22.139295]<osimons>missed you, Hodgestar :-)
[05:36:47.806023]<davidfraser>Hodgestar: osimons nearly cried when you left
[05:36:53.817865]<osimons>Hodgestar: how about a config setting for the tool? with fail_on_warnings = false as default?
[05:37:19.754795]<Hodgestar>davidfraser: :P
[05:37:52.252489]<Hodgestar>osimons: I don't think there is a tool currently -- I just run pylint with sh:exec.
[05:37:58.279357]<Hodgestar>osimons: Should I make one?
[05:38:28.828628]<osimons>ah - of course. there is no tool for running it. slow today - still holiday... (excuse)
[05:38:52.261804]<osimons>Hodgestar: you can run lint as part of the distutils stuff, i think?
[05:39:10.922765]<osimons>no, you can't. let me check my example recipes.
[05:40:10.292073]<osimons>right, my examples have either:
[05:40:13.121560]<osimons> <sh:exec executable="pylint" output="pylint.out" args="--output-format=parseable bitten" />
[05:40:21.098145]<osimons>or
[05:40:21.958202]<osimons><python:exec module="pylint.lint" output="pylint-report.txt" args="--output-format=parseable bitten" />
[05:40:30.790733]<osimons>same same
[05:42:19.487973]*asmodai continues fixing Babel bugs
[05:42:23.279728]<osimons>but yes, is it natural that the task of running and reporting is separated? ie. should python:pylint really be one tool that runs and reports, Hodgestar?
[05:42:41.852555]<osimons>asmodai: babel rules! i think...
[05:43:13.738781]<Hodgestar>I don't know. I quite like the separation. It means one can write one's own custom pylint (or unittest or whatever) if one feels like it.
[05:43:51.888528]<osimons>all right - agree, and it is of course like other tools generally works
[05:44:16.527977]<osimons>- which if very often a cause of confusion of course as people expect a lint tool to actuall run lint...
[05:44:39.363933]<Hodgestar>I suppose it is.
[05:45:06.976340]<Hodgestar>What about some option on sh:exec to say which exitcodes should be considered success?
[05:45:29.474443]<Hodgestar>Not wild about that either it's just the best idea I've had so far.
[05:45:44.725505]<osimons>in general the tools should naturally group a task, but of course an option or a config could tune individual runs. like your separation could be an argument for those "in the know" that wants to separate - to just execute, or to just report
[05:45:51.965458]<osimons>- right. same same.
[05:46:39.004057]<Hodgestar><easy:pylint /> ?
[05:47:03.151983]<osimons>so python:pylint could have options to report=true and execute=false as default => same behaviour as today?
[05:47:15.287810]<osimons>not really considered this of course
[05:48:43.456697]<osimons>Hodgestar: cause, really only pylint tool can reasonably expect to normally produce the output consumed by our reporting tool?
[05:50:20.762646]<osimons>asmodai: we'll surely ping you when hodgestar & davidfraser starts on the Bitten i18n subproject... :-)
[05:50:22.611490]<Hodgestar>pylint is already crazily configurable so I can't think of any good reason to write something else that would produce pylint output.
[05:50:55.219696]<Hodgestar>osimons: davidfraser is secretly an i18n expert. :)
[05:50:56.568561]<osimons>right - and if you did write some other tool, the surely you'd be capable of tweaking a small bitten runner too...
[05:52:17.630807]<Hodgestar>Unless you're just using the superlint someone else wrote.
[05:53:02.264554]<osimons>right - then use the python:superlint tool in bitten :-)
[05:54:46.892172]<osimons>i don't know, but hear from cruicecontrol and others that they pick a task and configure it and then it is ready to run. in bitten, the use of 1 command-line to run and 1 reporting tool to report is somewhat less intuitive
[05:55:14.211754]<Hodgestar>I think moving Bitten towards merging running / reporting things like pylint in one step sounds good. With the idea that it will initially default to just reporting as they do now.
[05:56:09.813660]<Hodgestar>I'll have to go through all the commands to see what the effect on c:, java:, etc might be.
[05:56:18.076969]<Hodgestar>Maybe this is something worth mailing the list about.
[05:57:14.752731]<osimons>yeah, i suppose - as a target for 0.7
[05:58:05.646395]<Hodgestar>It feels like a fairly big change without major benefits though -- and there is a lot of other work to do.
[05:58:11.718339]<osimons>or, if not breaking changes then 0.6.x is fine too
[05:59:03.424548]<osimons>Hodgestar: one tool at a time, so if python:lint gains a new optional argument to also run lint, or name the module to run or whatever, it will execute it if the argument is set. no big change.
[06:01:02.016854]<Hodgestar>Hmm. This fits less well with things like python:unittest and python:figleaf / python:coverage where a single executable produces output for multiple report commands.
[06:01:36.451068]<osimons>yeah, that testrunner is somewhat special though - python only, and a large extension for making all kinds of stuff.
[06:03:23.817049]<osimons>you could of course adapt that tool to add lint running - in general i suppose you want lint information for the same source as you report coverage from?
[06:04:57.742669]<osimons>add a --lint-summary="" argument that runs lint if specified and outputs to the specified summary file?
[06:05:28.587525]<asmodai>osimons: sure
[06:05:39.120571]<asmodai>osimons: Good enough to fix and implement now anyway
[06:07:51.286301]<osimons>asmodai: i dread getting started on l10n/i18n for bitten and my various plugins, but would likely get easier if i'd done it for the first one.
[06:08:26.628361]<osimons>- and i don't see how the user base of bitten, fullblog and other plugins is going to be substantial enough to keep translations up-to-date...
[06:09:00.860878]<osimons>we can adapt it to a global audience, and be stuck with english-only anyway...
[06:12:11.430761]<Hodgestar>My other solution is <sh:exec executable="python" args="-c "from subprocess import call; import sys; ret = call('pylint --args'); sys.exit(ret if (ret > 31 or ret < 0) else 0)"" /> (with a little more escaping).
[06:12:38.527514]<Hodgestar>I guess it helps to have some kind of translation tool so that a translator who doesn't know coding can submit something in 15 minutes.
[06:14:20.351883]<osimons>Hodgestar: add the hack to docs and be done with it :-)
[06:46:27.503678]<davidfraser>It really really helps to have translation tools. babel rocks for making it easy to get the translations to translators in a useful fashion...
[06:46:56.797139]<davidfraser>but as osimons says I think the question is, is now the right time to focus on translatability?
[06:53:10.269094]<Hodgestar>Probably not.
[06:53:41.484565]<asmodai>Well
[06:53:48.772533]<asmodai>you can always add the extraction stuff
[06:53:57.414479]<asmodai>and not translate anything at the moment
[06:54:02.541149]<asmodai>It saves you time in the long run.
[07:01:56.599134]<davidfraser>Yes that's a plan
[10:18:00.272814]<Hodgestar>osimons: If I'm going to commit a documentation update do I need to do anything other than run "python setup.py build_doc" and "python setup.py test_doc" before I commit?
[10:18:11.800311]<Hodgestar>And how to document changes propagate to the web site?
[10:19:06.137101]<osimons>Hodgestar: docs are included using an [[include]] macro - so they are read straight from trunk - see http://bitten.edgewall.org/wiki/Documentation/commands.html?action=edit
[10:20:28.167217]<osimons>Hodgestar: the build docs are not part of the source in repos, so just build for your own testing - open doc/index.html in browser and make sure changes look ok => commit
[10:20:54.472967]<Hodgestar>Woot. Thanks.
[10:21:02.988766]<osimons>i've never run test_doc - sounds interesting :-)
[10:21:09.150976]*osimons tries
[10:21:36.975298]<Hodgestar>I saw it in setup.py so I ran it. :)
[10:21:45.904599]<osimons>ah. seen that before. right. not quite sure what it does, but anyway....
[10:23:24.202442]<Hodgestar>It runs doctest on any code it finds in the documentation.