On Mon, Jun 25, 2012 at 18:11 +0100, Floris Bruynooghe wrote: > On 25 June 2012 15:36, holger krekel <hol...@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 _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
