Allow marking fixtures as always-indirect

[michallowasrzechonek-silvair]

closes #10101

• [x] Include documentation when adding new features.

• [x] Include new tests or update existing tests when applicable.

• [x] Allow maintainers to push and squash when merging my commits. Please uncheck this if you prefer to squash the commits yourself.

• [x] Create a new changelog file in the changelog folder, with a name like <ISSUE NUMBER>.<TYPE>.rst. See changelog/README.rst for details.

• [x] Add yourself to AUTHORS in alphabetical order.

[mrzechonek]

@RonnyPfannschmidt is there anything I could do to improve this and get it merged? :)

[michallowasrzechonek-silvair]

@RonnyPfannschmidt ping?

[RonnyPfannschmidt]

I haven't been able to allocate some time to understand the exact implications,

As I m surprisingly going to be a father again today i won't be able to look at this timel

@nicoddemus can you give it a look

[michallowasrzechonek-silvair]

Congratulations!

[nicoddemus]

Sorry for the delay.

@RonnyPfannschmidt you mentioned that you wanted to brainstorm a better name for the parameter.

@michallowasrzechonek-silvair you said you didn't want to require users to add @parametrize to all their tests, but they still need to do that in order to give the parameters, correct?

[RonnyPfannschmidt]

The more I think about it, the more this is a spooky action at a distance

I'd like to find a more explicit way to sort this out

[michallowasrzechonek-silvair]

Not really. This is about the need to add indirect=["foo"] to all usages of parametrize, if fixture foo is meant to be indirectly parametrized.

I think "indirect" is rather a property of the fixture (part of its API) than a property of the invocation.

[RonnyPfannschmidt]

It ought to be a part of the parameterization as its telling whether its OK to pass something to a fixtures or if it should be used directly

[michallowasrzechonek-silvair]

Did you have a chance to assess if this is a good idea? If it isn't, I'm OK with closing.

[RonnyPfannschmidt]

I believe the naming requires some bikeshedding

What we want is a fixture that always needs a parameter

Indirect is barely comprehensible for Parametrize, but for fixtures it's mind-boggling

First ideas for the name are require_parameters, but I'm sure we can do better with some brainstorming

Im under the impression that it is necessary to follow up with a bad integration of lazy fixtures in core with a way to spell out fixture dependencies with parameters

[michallowasrzechonek-silvair]

What we want is a fixture that always needs a parameter

Yes! Thanks for spelling it out like that, it's much clearer.