Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deprecate resultlog #830

Closed
RonnyPfannschmidt opened this issue Jul 11, 2015 · 15 comments
Closed

deprecate resultlog #830

RonnyPfannschmidt opened this issue Jul 11, 2015 · 15 comments
Labels
type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Milestone

Comments

@RonnyPfannschmidt
Copy link
Member

the format is incomplete and tricky to parse,
i propose deprecating it in 2.8 and scheduling full removal for when pypy uses something more modern

a more complete replacement will be proposed at a later point in time

@RonnyPfannschmidt RonnyPfannschmidt added this to the 2.8 milestone Jul 11, 2015
@nicoddemus
Copy link
Member

Hmm I have never used it... could you explain the motivation for the plugin to exist in the first place and what pypy has to do with it?

I kind of agree about it being difficult to parse... perhaps it would be better to produce the contents in something easier to parse, like JSON perhaps?

Thanks!

@RonnyPfannschmidt
Copy link
Member Author

resultog is basically the first variant of semi-structured output of test results for later consumption

it was created years before json was as well known as today

pypy uses it for its execution result analysis

these days a format like subunit or a general stream of json objects (one per line) seems far more helpful

such a format could also be used for more detailed pytest debugging, (since trace items could be part of sucha stream without creating unwanted intersection)

@nicoddemus
Copy link
Member

I see, thanks for the explanation! 😄

@nicoddemus nicoddemus added the type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature label Jul 12, 2015
@RonnyPfannschmidt RonnyPfannschmidt modified the milestones: 2.8, 2.8.dev Sep 18, 2015
@nicoddemus
Copy link
Member

Should this be updated to 2.9 now that 2.8 is out already?

@RonnyPfannschmidt RonnyPfannschmidt modified the milestones: 2.9, 2.8.1 Sep 27, 2015
@RonnyPfannschmidt RonnyPfannschmidt changed the title deprecate resultlog in 2.8 deprecate resultlog in 2.9 Sep 27, 2015
@The-Compiler The-Compiler modified the milestones: 2.10, 2.9 Feb 26, 2016
@The-Compiler The-Compiler changed the title deprecate resultlog in 2.9 deprecate resultlog Feb 26, 2016
@nicoddemus nicoddemus modified the milestones: 2.10, 3.0 Jun 26, 2016
@The-Compiler
Copy link
Member

Should we do this for 3.0 as it's backwards-incompatible but probably relatively straightforward?

@RonnyPfannschmidt
Copy link
Member Author

yes please

nicoddemus added a commit to nicoddemus/pytest that referenced this issue Aug 16, 2016
nicoddemus added a commit to nicoddemus/pytest that referenced this issue Aug 16, 2016
nicoddemus added a commit to nicoddemus/pytest that referenced this issue Aug 17, 2016
@nicoddemus
Copy link
Member

Fixed in #1812

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

5 participants