[py-dev] Storing terminal width in py.test config object
holger at merlinux.eu
Tue Jun 26 09:43:58 CEST 2012
On Mon, Jun 25, 2012 at 18:11 +0100, Floris Bruynooghe wrote:
> On 25 June 2012 15:36, holger krekel <holger at merlinux.eu> wrote:
> > On Mon, Jun 25, 2012 at 16:09 +0200, Ronny Pfannschmidt wrote:
> >> given the nature of the problem,
> >> i think its wrong to go for terminal width there,
> >> instead we should serialize the exponations,
> >> and render them on the master.
> >> that way we could also have other ways of display more nicely.
> > It's indeed true that a frontend-independent format that can be
> > rendered on the master would be nice ... um, html? (not sure it's a joke).
> Not sure that would cover all situations, py.io.saferepr() would
> somehow have to serialise the full thing (which might be simply too
> much data) and the other side would have to then notice this and
> somehow figure out the right argument for the maxsize argument of
> saferepr. I'm sure there's a way of encoding all that but that but
> it's a lot of complexity and still won't solve the too much serialised
> data problem.
What about a "reportsettings" object with all neccessary settings
(including maxsize, tb-represenation defaults, ...) which slaves use to
parametrize their reporting? We should then also allow reading
reportsettings from the ini-file and let cmdline options override them.
Particulary with respect to coloring/bold effects, i'd still want a
more abstract representation of output than plain (ansi-colored)
strings, i think. It should allow to easily produce html-output or to adapt
to windows/unix terminal coloring styles. This is some effort to get right
but it can at least be tested separately.
In general, i'd target the following goals with such a refactoring:
* a new --htmlreport option to produce html-output (maybe with a little
* colored,linewidth adapted terminal output for xdist on all platforms
* much less network/cpu usage for long failure reps if --tb=native/no
Additionally, if we manage to get most of this functionality into pylib,
detox might also make use of it as it aims to support cross-host distributed
testing on a different level.
More information about the Pytest-dev