Re: long name in logs, passing ids=... to parametrize would allow you to customize it to a shorter form.

(which might also work around the env issue? unclear, but we should fix that anyway.)

Thanks, passing ids=... works around the env issue too:

@pytest.mark.parametrize(
    "test_input",
    [
        "1",
        "2",
        "[" * (1024 * 1024),
        "{" * (1024 * 1024),
    ],
    ids=["a", "b", "c", "d"]
)
def test_long_input(test_input):
    pass

(Although there are 30 params in the real test, so I'd opt for the method splitting workaround in this case.)

(Although there are 30 params in the real test, so I'd opt for the method splitting workaround in this case.)

Note that you can pass a function to ids instead (docs). Thus, you could do something like ids=lambda s: s[:10] (assuming that your IDs are still unique after that).

i believe this is one of the c ases where pytest should not consider the string as valid id and hint and pasing a explicit name, autogenerating the test name instead

aka "{"*10000 should result in a warning and a autogenerated test id
the suggestion should be to use pytest.param(""{"*10000, id="intent-of-the-input"

@RonnyPfannschmidt / @nicoddemus any recommendations on where the fix should live? but where do we draw the line here? a few queries from my initial investigation:

• _pytest/python.py (add some checks around validating ids here - could you recommend where this issue should typically be solved?
• Do we auto generate a random name after a certain amount? checking length of nodeid plus the parametrized data (plus various bolts on like '[] teardown' to account for worse case scenario when updating PYTEST_CURRENT_TEST in environ are problematic.
• Do we say, if your value is over 'X' in length, we will auto generate one for you (shorter - only on windows) and alert you to the fact? I'm not sure how potentially breaking that is tho to current windows tests as some may be using slightly longer. my initial thought was if the data is > 1024 we will rewrite it but ultimately from what I gather the entire environment path on windows cannot exceed the 32.7K limit so part of me feels like its a futile effort of a fix in vain because if you just do enough shorter ones, same problem will persist?

I would draw the line around 100, maybe less

ok I will mock something up and discuss via PR, I think we have a few areas where maybe we should consider a --windows based flag that does a couple of things, 2-3 issue's ive seen are similar in nature to this but in different parts of the system, relating to file lengths or env var lengths etc :)

Any progress on this issue? We were still able to replicate it with latest pytest (3 years later). Was this just forgotten about, or is it a wontfix?

Even worse, it seems that doing:

@pytest.mark.skipif(platform.system() == "Windows", reason="environment variable limit on Windows")
@pytest.mark.parametrize(("string"), ["a" * (32768)])
def test_write_utf_limit(string):
    ...

Causes the test to be skipped, but also failed somehow. I suspect that it's because the error occurred during parametrization, so even though the test function didn't actually run, it still failed. See: commit that caused this, along with the corresponding failure in it's CI run

Although the suggested fix by setting ids does work, it seems like something that should be addressed, if possible.

Nobody took the time to fix it, but a pull request would be certainly welcome.

The open pull request went stale it seems

@symonk - the discussion here points to following a different approach, so I think it's ok to close this one then, right?

@obestwalter I opened this issue, and @symonk opened a PR linked to this issue.

Is "close this one" referring to the PR linked to this issue, or is it referring to this issue?

@kurtmckee yes it's about the PR that is not the preferred solution anymore. I actually should have written it there. Thanks for clearing that up.

Thanks @kurtmckee for picking this up, let's move the discussion back here then as the first PR to address this is likely to be closed soon then.

You wrote:

1. Detect long IDs (cross-platform for consistency)
2. Hash the IDs to avoid platform-specific length restrictions
3. Issue a warning suggesting ways to choose IDs independently

My head is spinning from going through tons of Issues and PRs over the last few days after not really having followed the developments for a long time. But from my shallow understanding doing it like this is fixing the problem and letting the user know that something potentially surprising has been done to address it, giving them the info needed to handle it differently if they so wish. So sounds like a good plan to me.

I agree with #7254 (comment) too.