Seems like a sane approach at first sight. What are the risks to breaking plugins which rely on the collection nodes? I'm guessing fairly small as there are just some new intermediate collection nodes.
Thanks for your perseverance in this battle to sort out marks! Floris On 23 May 2017 at 14:28, RonnyPfannschmidt <[email protected]> wrote: > Hi everyone, > > first let me link https://github.com/pytest-dev/pytest/labels/mark-issue > those issues give a basic idea on how badly mark is broken and how it > breaks things for users > > (we had some people rewrite their complete testsuites to deal with the > fallout of how bad it is) > > a few basic underpinnings already happened in pytest 3.1 with > `pytest.param` and the internal restructuring of marker values > > whats missing now is to bring marks onto the collection tree not as a > bastardized broken and inconsistent version of keywords, but as actual > marker objects, without any of the breakages and inconsistencies we see > today > > in order to do that i see a need for a new property on all nodes where > the markers of a node are discover-able (get_marker is broken beyond > repair i'm not going to fix that before we can get a correct view of marks) > > this property can then be used to pass over marks of the ndoes, the > parent nodes and so on, in order to get a consistent view on markers for > an item > > in order to make this work consistently with parameterization, > i will introduce a FunctionDefinition node (and a function-definition > scope), that will upon collection apply the parameters (and invoke the > generate_tests hook (also now we will be able to give metafunc a correct > view of marks) > > and then a function node will just be the final parameterized call to a > function definition, > > in order to ensure this works nicely, > i will introduce a pytestmark property on all marked functions, > that acts like the attribute property on classes, but will not be > affected by the legacy marker transfer > > once we have a basic clean data-set for markers on all nodes we can > begin to fix up apis like get_marker and/or deprecate as we see need > > in the next step we can introduce opt-outs of the old and staining > marking mechanim and prepare for a truly breaking release > > -- Ronny > > _______________________________________________ > pytest-dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/pytest-dev _______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
