[pytest-dev] progressing with fixing mark, a potentially backward compatible path to progression

[RonnyPfannschmidt]

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
> <opensource at ronnypfannschmidt.de> 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
>> pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev