Lockfile does not generate correct version requirements for 3.9 when run locked on 3.8, under certain circumstances

[gitpushdashf]

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
rich = "*"

[dev-packages]
mypy = "*"

If I generate the lockfile (pipenv 2022.3.28 or 2022.4.8) on Python 3.8, it looks like this:

% tail -n 10 Pipfile.lock
        "typing-extensions": {
            "hashes": [
                "sha256:1a9462dcc3347a79b1f1c0271fbe79e844580bb598bafa1ed208b94da3cdcd42",
                "sha256:21c85e0fe4b9a155d0799430b0ad741cdce7e359660ccbd8b530613e8df88ce2"
            ],
            "markers": "python_version < '3.9'",
            "version": "==4.1.1"
        }
    }
}

If I generate the lockfile on Python 3.9, it correctly looks like this:

% tail -n 10 Pipfile.lock
        "typing-extensions": {
            "hashes": [
                "sha256:1a9462dcc3347a79b1f1c0271fbe79e844580bb598bafa1ed208b94da3cdcd42",
                "sha256:21c85e0fe4b9a155d0799430b0ad741cdce7e359660ccbd8b530613e8df88ce2"
            ],
            "markers": "python_version >= '3.6'",
            "version": "==4.1.1"
        }
    }
}

This seems to be caused by rich requiring typing-extensions only on Python 3.8 and older, whereas mypy always requires it: https://github.com/python/mypy/blob/master/mypy-requirements.txt#L1

rich: https://github.com/Textualize/rich/blob/master/pyproject.toml#L30

This breaks mypy when installed alongside rich on 3.9+, when the lockfile is generated on 3.8.

[matteius]

@gitpushdashf I believe this is similar to another reported issue #4967 that I believe will be fixed, or at least deterministic when the vendoring to pip 22.0.4 can be completed. At least I will have you re-test when we can get to that point.

[gitpushdashf]

Sounds good, thank you!

[matteius]

Please check with pipenv==2022.4.20

[gitpushdashf]

Still having the same issue.

[matteius]

@gitpushdashf This may be solved by the nondeterminism in markers issue -- there is a branch out for it you could check: #5373

[matteius]

@gitpushdashf marker determinism should be solved with pipenv==2022.9.24

[gitpushdashf]

Awesome! Thank you so much! Will test later.