Ronny Pfannschmidt

As far as I understood, the use case is already implementable by just adding fixtures to those classes, I'm strictly opposed just magically adding calling those methods as the composition...

at first glance this is a issue with node id computation messing up with relative pathnames, thanks for providing the comprehensible example, we need to add it to the testsuite

as far as i can tell `pytest.fixture_request('default_context')` in the proposal is roughlymatchingt of the lazy fixture as far as specification/declaration goes from that i can also tell is that lazy_fixtures...

@TvoroG no, the parametrization is pretty hard to solve, and not necessarily correct that way imagine a local override of a requested parameter fixture that changes parameter counts/values or even...

```python @fixture(params=["a", "b", "c"]) def moarfun(request): return request.param @fixture(params=[1,2,3]) def whops(request, moarfun): return request.param @pytest.mark.parametrize('a', [ lazy_fixture('whops'), # not clear how to expand lazy_fixture_ex('whops', params=[1,2,3]), # dito lazy_fixture_ex2('whops', param=1), #...

@rajibmitra until pytest_layz_fixtures is actually up to the task merging it to the core is taking on technical debt with high interest and low payback probability - so no

Nope

@gomri15 feel free to start on this

I'd like to have a more detailed discussion about structuring the collection tree, we accrued a mess that requires some decomposition to begin with

its really not clear whats happening there, its just clear that python itself gets seg-faulted, which is quite a feat and a real pain to debug