[Major] Improve the fixture union engine to support hybrid param+fixture mode

[smarie]

The latest developments about test ids uniformization, as well as #146 and pytest-dev/pytest#8155, made me realize that maybe the fixture union engine could be extended to natively support hybrid param+fixture unions.

If this works this would have two benefits:

• first, @parametrize would not have to generate a global union fixture for the parameters as of today, immediately solving when @parametrize finds a fixture_ref in its argvalues, the parameter is not anymore accessible through request.getfixturevalue #146
• second, @parametrize would not have to generate one fixture per group of parameters, so in particular @parametrize_with_cases would probably be much more efficient (far less fixtures generated, only when a case requires a fixture)

However... it will probably be hard to do. A few things to do:

• UnionFixtureAlternative.to_list_of_fixture_names will have to only return only the fixtures and not the parameters

  python-pytest-cases/pytest_cases/plugin.py

  Line 295 in aeb72ef

  alternative_f_names = UnionFixtureAlternative.to_list_of_fixture_names(_params)

  so that FixtureClosureNode._build_closure can understand

  python-pytest-cases/pytest_cases/plugin.py

  Line 246 in aeb72ef

  def _build_closure(self,

• modify the calls reactor behaviour when it receives a Union Param

  python-pytest-cases/pytest_cases/plugin.py

  Line 760 in aeb72ef

  if is_fixture_union_params(argvalues):

  and when it processes it:

  python-pytest-cases/pytest_cases/plugin.py

  Line 834 in aeb72ef

  def create_call_list_from_pending_parametrizations(self):

• finally checking how the ids in all the tests will evolve and how/if we should adapt idstyle

Not an easy ride but might be worth the shot in 2021

[smarie]

After sleeping on this I think the right order would better be:

• 1. @parametrize does not need to create a test wrapper anymore. It needs to stop creating ParamAlternatives and instead just pass the argvalues as is. All argvalues containing fixture_ref, possibly marked, possibly nested in tuples, etc., need to be replaced with an easier to use object for example ValueWithFixtureRefs, remembering if the fixture ref is used for the whole tuple or for parts of it (possibly several).
• 2. in FixtureClosureNode._build_closure, we should check that the corresponding parameter still pops in the received list. There is a need to detect that this parameter is special (because it contains fixture_refs). For this, the argvalues are currently inspected with

     python-pytest-cases/pytest_cases/fixture_core1_unions.py

     Line 15 in b0681bb

     from inspect import signature, Parameter

     . This should therefore be modified so that it returns true if at least one ValueWithFixtureRefs is detected in the list.
• 3. In the pytest_runtest_setup hook, this special ValueWithFixtureRefs object will probably need to be resolved using request._getfixture (?). For this a convenience ValueWithFixtureRefs.resolve(self, request_or_item) method on the object seems appropriate.

     python-pytest-cases/pytest_cases/plugin.py

     Line 60 in aeb72ef

     def pytest_runtest_setup(item):

[smarie]

Another way to say the above is "before I thought that fixture unions were the core and parametrize would reuse this, but we have to revert this pattern: a fixture union is "just" a parametrized fixture with only fixture_ref argvalues. So @parametrize should be the core mechanism.

Another thing we'll need to do in this refactoring, as discussed in #158, is to support parametrized lazy_value and lazy_value requiring fixtures. This would enable us to remove all the fixture-creating "tricks" in @parametrize_with_cases.

This plan becomes clearer and clearer, I'm optimistic for 2021 ! But as always, devil will be in the tiny details: custom ids, custom marks, custom fixture scopes, etc.