[py-dev] Storing terminal width in py.test config object

[holger krekel]

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
  javascript to fold/unfold tracebacks etc.)

* colored,linewidth adapted terminal output for xdist on all platforms

* much less network/cpu usage for long failure reps if --tb=native/no
  is supplied

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.

best,
holger