i don't even want to guess the risk, the related code feels like the kind of spaghetti that happens after composite materials polymerize
^^ -- Ronny Am 29.05.2017 um 13:39 schrieb Floris Bruynooghe: > 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
