[Python-Dev] cpython (2.7): Issue #18441: Make test.support.requires('gui') skip when it should.
Ned Deily
nad at acm.org
Mon Jul 22 07:35:45 CEST 2013
In article <51ECAE41.5060403 at udel.edu>, Terry Reedy <tjreedy at udel.edu>
wrote:
> On 7/21/2013 10:11 PM, R. David Murray wrote:
> > On Mon, 22 Jul 2013 02:13:47 +0200, terry.reedy
> > <python-checkins at python.org> wrote:
> >> +# If buildbot improperly sets gui resource (#18365, #18441), remove it
> >> +# so requires('gui') tests are skipped while non-gui tests still run.
> >> +if use_resources and 'gui' in use_resources:
> >
> > Note that the buildbot cannot "improperly" set the GUI resource.
>
> I disagree. I do understand though, that what I call improper setting on
> the command line cannot be prevented. So I think regrtest (and unittest
> if and when it supports resources) should intercept 'gui', test once and
> for all whether it was set 'properly' (or 'appropriately', if you
> prefer), which is to say, test whether there is a usable GUI, and ignore
> 'gui' if not.
>
> > Setting a resource on the regrtest command line says "please try to run
> > these tests".
Right.
> When doing so causes a failure at best and a crash at worst, and those
> consequences and the means of avoiding them are not documented, that is
> not a very considerate request. It has cost me over a day of my life.
Unfortunately, that's the way regrtest resources work.
> The printed out -h help says
> "gui - Run tests that require a running GUI."
> Not 'try', but 'run'. That implies to me that there *is* 'a running GUI'
> and that is it all right to run tests that *require* such. That was also
> what I understood from the discussion on
> http://bugs.python.org/issue18103 Create a GUI test framework for Idle
This is exactly what Issue8716 was about. The buildbot has no way of
knowing ahead of time whether a test will cause a crash or not. Yes, Tk
should not crash but it does in some cases. Speaking of #8716, that
reminds me that there is an open issue with it (documented in
Issue17496). There is the start of a patch there to use a more general
approach to testing for a working Tk that might be applicable on all
platforms.
--
Ned Deily,
nad at acm.org
More information about the Python-Dev
mailing list