Allow parametrize to depend on previous parametrize

[Anton3]

Closes: #13233

[RonnyPfannschmidt]

the exposure of callspec, the hook order change as well as future considerations make this one extra hard to review

I'll need to schedule something for that

[RonnyPfannschmidt]

We should introduce a new method name for this and mark it experimental to avoid locking into callspec as exposed api too early

I'm not sure what a fitting name would be

[Anton3]

An alternative to exposing CallSpec is, as I said, to add a new Node subtype with an additional getparam method. If it was a Node, the hook from docs

    def pytest_generate_tests(metafunc: pytest.Metafunc):
        if "bar" in metafunc.fixturenames:
            # parametrize "bar" arg based on "bar_params" mark
            base_bar_marks = list(metafunc.definition.iter_markers("bar_params"))

            def gen_params(callspec: pytest.CallSpec):
                # collect all marks
                bar_marks = base_bar_marks + [
                    mark for mark in callspec.marks if mark.name == "bar_params"
                ]
                # collect all args from all marks
                return [arg for mark in bar_marks for arg in mark.args]

            metafunc.parametrize("bar", gen_params)

would be rewritten as just:

    def pytest_generate_tests(metafunc: pytest.Metafunc):
        if "bar" in metafunc.fixturenames:
            def gen_params(proto_item: pytest.ProtoItem):
                bar_marks = proto_item.iter_markers("bar_params")
                return [arg for mark in bar_marks for arg in mark.args]

            metafunc.parametrize("bar", gen_params)

[RonnyPfannschmidt]

I would like to avoid using nodes or node lookalikes

In fact thinking about potentially nesting and/or cascading I'd like to defer inventing new apis

Just ensuring the apis to experiment/ learn from this are experimental

We can't hope to initially account for something like acting in the bases of mark coming in from lazy fixtures

[Anton3]

@RonnyPfannschmidt I've figured out the ordering issue I struggled with

I can add parametrize_experimental that has everything of the normal parametrize, plus the new feature. What do you think?

[RonnyPfannschmidt]

im struggling wit the naming still

instead of expanding parametrize, i'd like to see a new name that only offers the new feature and is marked as experimental api

something like parametrize_dependent as name for both the marker on the tests as well as the function name on metafunc

that way the oder issue would also resolve as the default implementation could just invoke the parametrize_dependent after parametrize

im still very torn on the naming issue

i think its a good idea to keep a distinction between parametrize thats just defined and parametrize thats computed based on other parameters

[tjkuson]

Hi @Anton3, do you plan to continue working on this PR? This functionality would be really helpful for a problem I am trying to solve. If not, I'd be willing to continue where you left off/open a new PR.