Repository: pypa/pipenv

Issue:
Pipenv lock changes markers in a non deterministic way
### Issue description

I'm running pipenv version 2020.11.15 in a Gitlab CI pipeline.
I use `pipenv lock` and then `git diff Pipfile.lock` to see if the Pipfile.lock was updated, meaning that the version on the repository is not up-to-date anymore.

Occasionally, pipenv updates the lock file just changing the Python 4 specifier as follows:
```diff
diff --git a/Pipfile.lock b/Pipfile.lock
index c8d17c6..0228d56 100644
--- a/Pipfile.lock
+++ b/Pipfile.lock
@@ -225,7 +225,7 @@
                 "sha256:0a943902919f65c5684ac4e0154b1ad4fac6dcaa5d9f3426b732f1c8b5419be6",
                 "sha256:2bb1680aad211e3c9944dbce1d4ba09a989f04e238296c87fe2139faa26d655d"
             ],
-            "markers": "python_version >= '3.6' and python_version < '4.0'",
+            "markers": "python_version >= '3.6' and python_version < '4'",
             "version": "==5.8.0"
         },
         "jedi": {
@@ -881,7 +881,7 @@
                 "sha256:2f4da4594db7e1e110a944bb1b551fdf4e6c136ad42e4234131391e21eb5b0df",
                 "sha256:e7b021f7241115872f92f43c6508082facffbd1c048e3c6e2bb9c2a157e28937"
             ],
-            "markers": "python_version >= '2.7' and python_version not in '3.0, 3.1, 3.2, 3.3, 3.4' and python_version < '4.0'",
+            "markers": "python_version >= '2.7' and python_version not in '3.0, 3.1, 3.2, 3.3, 3.4' and python_version < '4'",
             "version": "==1.26.4"
         },
         "wcwidth": {
```

And sometimes it does the opposite thing, changing from `python_version < '4'` to `python_version < '4.0'`.
This of course breaks the pipeline, because there is difference in the Pipfile.lock, even though that difference is not significant.

### Expected result

pipenv lock should change the lock file in a deterministic way, either always with `python_version < '4'` or `python_version < '4.0'`.


Discussion:
As a temporary workaround, I am removing the `"markers": "python_version` lines before comparing the old and new Pipfiles.

Here the section of my `.gitlab-ci.yml`:
```yaml
pipenv:
  stage: analysis
  script:
    - cp Pipfile.lock Pipfile.lock.old
    - pipenv lock
    - sed -i '/\"markers\":\ \"python_version/d' Pipfile.lock # remove markers
    - sed -i '/\"markers\":\ \"python_version/d' Pipfile.lock.old # remove markers
    - git --no-pager diff --no-index Pipfile.lock Pipfile.lock.old | tee diff.log
    - RESULT=$( head -n 1 diff.log | { grep -o 'diff' || true; } )
    - RETURN=0
    - if [ "$RESULT" = "diff" ]; then RETURN=1; echo "Something changed!"; fi 
    - exit $RETURN
  after_script:
    - pip install anybadge
    - RESULT=$( head -n 1 diff.log | { grep -o 'diff' || true; } )
    - SCORE=passed
    - if [ "$RESULT" = "diff" ]; then SCORE=outdated; echo "Something changed!"; fi 
    - anybadge -l pipenv -v $SCORE -f pipenv.svg outdated=red passed=green
  artifacts:
    paths:
      - pipenv.svg
      - diff.log
    when: always

```
Hi, I am also getting this result, but on every  ``pipenv lock`` call. It just goes back and forth between ``'4'`` and '``4.0'``.
Something changed in the latest version, now I am getting both `python_version` and `python_full_version` markers.
The following change to the `.gitlab-ci.yml` works

```yaml
 - sed -i '/\"markers\":[[:print:]]*python_[[:print:]]*version/d' Pipfile.lock  # remove markers
 - sed -i '/\"markers\":[[:print:]]*python_[[:print:]]*version/d' Pipfile.lock.old  # remove markers
```
@matpompili and @jshwi please see:  https://github.com/pypa/pipenv/issues/4967
TLDR:  Pip 22.0.4 upgrade branch seems to make this deterministic again.  

Closing this ticket now since we are already tracking it in the newer ticket.
Still having the same behaviour after upgrading to pip 22.0.4. Using pipenv 2022.5.2:
```diff
diff --git tasks/Pipfile.lock tasks/Pipfile.lock
index f039f8175..086dbcb0c 100644
--- tasks/Pipfile.lock
+++ tasks/Pipfile.lock
@@ -68,7 +68,7 @@
                 "sha256:211800f725cdecedcbcf4c753bbd22d248312b37d130f06045434acb7d9b34e1",
                 "sha256:35dd9063244263e63bd0bd24ea61e3015b00272cead084b2c40d788b0f857c46"
             ],
-            "markers": "python_version >= '3.7' and python_version < '4.0'",
+            "markers": "python_version >= '3.7' and python_version < '4'",
             "version": "==1.10.0"
         },
         "certifi": {
```
reproduced with pip 22.1 as well.

...is it just me?
> Still having the same behaviour after upgrading to pip 22.0.4. Using pipenv 2022.5.2:
> 
> ```diff
> diff --git tasks/Pipfile.lock tasks/Pipfile.lock
> index f039f8175..086dbcb0c 100644
> --- tasks/Pipfile.lock
> +++ tasks/Pipfile.lock
> @@ -68,7 +68,7 @@
>                  "sha256:211800f725cdecedcbcf4c753bbd22d248312b37d130f06045434acb7d9b34e1",
>                  "sha256:35dd9063244263e63bd0bd24ea61e3015b00272cead084b2c40d788b0f857c46"
>              ],
> -            "markers": "python_version >= '3.7' and python_version < '4.0'",
> +            "markers": "python_version >= '3.7' and python_version < '4'",
>              "version": "==1.10.0"
>          },
>          "certifi": {
> ```
> 
> reproduced with pip 22.1 as well.
> 
> ...is it just me?

I'm getting this as well.
Sounds like pip released a new version that may have changed in it, but pipenv vendors in pip 22.0.4 and nothing has been done to test the new version of pip.  Perhaps this is a pip bug.
Want to check the behavior of the newly vendored `pip==22.2.1` that is in main against this ticket because I saw something odd working on vistir where re-locking changed the markers from my initial lock (which had problematic markers).  If anyone has energy to see if they can reproduce this issue on `pipenv` main or not, will let me know if I need to track down a Pip issue report I read about once (where perhaps the fix for this was reverted).
Hey @matteius ,

using pip 22.2.1 and pipenv 2022.7.24 keeps altering `python_full_version` and `python_version` randomly:
```diff
diff --git tasks/Pipfile.lock tasks/Pipfile.lock
index 2149cfcdd0..2eeb60add2 100644
--- tasks/Pipfile.lock
+++ tasks/Pipfile.lock
@@ -84,7 +84,7 @@
                 "sha256:84c85a9078b11105f04f3036a9482ae10e4621616db313fe045dd24743a0820d",
                 "sha256:fe86415d55e84719d75f8b69414f6438ac3547d2078ab91b67e779ef69378412"
             ],
-            "markers": "python_full_version >= '3.6.0'",
+            "markers": "python_version >= '3.6'",
             "version": "==2022.6.15"
         },
         "cffi": {
```
I believe this is not an issue on the main branch as we force the usage of the vendor'd pip which eliminates the `using pip VERSION_X` with pipenv, as it uses a consistent version of pip for resolution.
Still having this on the latest pipenv which should have the fix, right?
@gitpushdashf Well technically it was vendoring of pip that fixed it and then we of course continue to vendor in new versions of pip as they are released.   We recently merged in a change that hasn't been released to force the environment to use the vendor'd version of pip in more places but it has not been released yet.  There are two possibilities -- one is that the version of pip you have installed doesn't match the version pipenv has vendored and that could perhaps create inconsistencies.  Or it is possible that something changed again in pip creating this inconsistency, but it was definitely pip vendoring that fixed it the prior time.
Interesting! I get the inconsistency between runs, however, on the same system. Could that happen from mismatched pip versions, locally?
These overly chatty diffs are slowing down our code reviews.

Would it be possible to create a command-line option `--use-local-pip` that causes `pipenv` not to use vendored `pip`?  Or a `--remove-markers-from-diff` option that implements https://github.com/pypa/pipenv/issues/4660#issuecomment-905424528 ?
@cclauss how would the `--use-local-pip` cause it to be less chatty? -- I think it would be more chatty because there would be more versions of pip in use for a project across users which would cause the markers to be different.  I'm not a big fan of user installed pips because it has created its own share of issues, plus for locking we never did use local pip, the resolver has always been vendor'd pip's internal APIs, and it wouldn't be possible to guarantee the local pip has same APIs.   We would also loose the index restricted packages patching, a patch for specifiers, and potentially some other things that the pipenv locking  behaviors rely on.  We dropped pip-shims (which is a good thing), so we really require locking to depend on `pip==22.2.2`

Also, we just merged in these two PRs that should help in a big way in the next release to not have the markers change during lock (though adding a new dependency could change the ordering, we'll have to see how that goes):
https://github.com/pypa/pipenv/pull/5286
https://github.com/pypa/pipenv/pull/5299

I'd recommend we see how that behaves in the next release.   We could consider a no-markers or remove-markers option, but I think that would also cause problems for packages that should have markers. 
I don't think this is fixed, unfortunately.

I ran locking once with the new 2022.8.30 version. I ran it again, and the lock file was the same.

However, the third time, I did get a difference:

```
diff --git a/Pipfile.lock b/Pipfile.lock
index 3fd567d..ad561b4 100644
--- a/Pipfile.lock
+++ b/Pipfile.lock
@@ -487,7 +487,7 @@
                 "sha256:0df5a63d74990b4d9318f8749bcb1c4b170799099e5f84cfef72c798f3d46db9",
                 "sha256:870e98c53b0f461065cce9db7be4864ea2ceb5de28dc97e1efa443a338f5ec28"
             ],
-            "markers": "python_version >= '3.7' and python_version < '4'",
+            "markers": "python_version >= '3.7' and python_full_version < '4.0.0'",
             "version": "==0.0.14"
         },
         "hos-simulator": {
@@ -715,7 +715,7 @@
                 "sha256:a6ea2b72ec4879b0265776df637ac4a5d1e4a7dc32fc7fca0c7abab38ee913be",
                 "sha256:e8a3ac93c1378623475e3561c3592392c447b03e7cba058f7c3fde026369213e"
             ],
-            "markers": "python_version >= '3.7' and python_version < '4'",
+            "markers": "python_version >= '3.7' and python_full_version < '4.0.0'",
             "version": "==0.9.1"
         },
         "python-dateutil": {
@@ -755,7 +755,7 @@
                 "sha256:419c4e67a2799bd1811f1284aea81488ca7fafbf3fe35724a0292f0b924e0807",
                 "sha256:a49e9ae54d2eb72b06c718e9d63721a1dc67b2f70e137a0ebeac3d035fa05a4c"
             ],
-            "markers": "python_version >= '3.7' and python_version < '4'",
+            "markers": "python_version >= '3.7' and python_full_version < '4.0.0'",
             "version": "==0.2.2"
         },
         "typing-extensions": {
@@ -778,7 +778,7 @@
                 "sha256:3fa96cf423e6987997fc326ae8df396db2a8b7c667747d47ddd8ecba91f4a74e",
                 "sha256:b930dd878d5a8afb066a637fbb35144fe7901e3b209d1cd4f524bd0e9deee997"
             ],
-            "markers": "python_version >= '2.7' and python_version not in '3.0, 3.1, 3.2, 3.3, 3.4, 3.5' and python_version < '4'",
+            "markers": "python_version >= '2.7' and python_version not in '3.0, 3.1, 3.2, 3.3, 3.4, 3.5' and python_full_version < '4.0.0'",
             "version": "==1.26.12"
         },
         "werkzeug": {
@@ -1587,7 +1587,7 @@
                 "sha256:3fa96cf423e6987997fc326ae8df396db2a8b7c667747d47ddd8ecba91f4a74e",
                 "sha256:b930dd878d5a8afb066a637fbb35144fe7901e3b209d1cd4f524bd0e9deee997"
             ],
-            "markers": "python_version >= '2.7' and python_version not in '3.0, 3.1, 3.2, 3.3, 3.4, 3.5' and python_version < '4'",
+            "markers": "python_version >= '2.7' and python_version not in '3.0, 3.1, 3.2, 3.3, 3.4, 3.5' and python_full_version < '4.0.0'",
             "version": "==1.26.12"
         },
         "webencodings": {

```
@gitpushdashf I've run `pipenv lock` on the pipenv project several times on the new `2022.8.31` and haven't seen the markers change yet -- wondering if you could check again?
I could reproduce this.

<details><summary>Pipfile</summary>

```toml
[dev-packages]
sphinx = "==4.*"
sphinx-click = "==4.*"
sphinxcontrib-spelling = "==7.*"
click = "==8.0.3"
stdeb = {version="*", markers="sys_platform == 'linux'"}
zipp = {version = "==3.6.0", markers = "python_version < '3.10'"}
pre-commit = "==2.*"
atomicwrites = {version = "*", markers="sys_platform == 'win32'"}
pytest-cov = "==3.*"
typing-extensions = "==4.*"

[packages]

[scripts]
tests = "bash ./run-tests.sh"
test = "pytest -vvs"

[pipenv]
allow_prereleases = true
```
</details>

<details><summary>script.sh</summary>

```bash
#!/usr/bin/env bash

pipenv --rm
pipenv lock --dev

for i in {1..10}:
do
    mv Pipfile.lock Pipfile2.lock
    pipenv lock --dev &> /dev/null
    echo "attemp $i"
    diff Pipfile.lock Pipfile2.lock | grep "markers"
done
```
</details>

<details><summary>Dockerfile</summary>

```Dockerfile
FROM archlinux

RUN pacman -Syu diffutils python3 python-pip --noconfirm
RUN python -m pip install --upgrade pip pipenv

WORKDIR /root
COPY Pipfile .
COPY script.sh .

ENTRYPOINT ["./script.sh"]
```
</details>

<details><summary>Result</summary>

```bash
No virtualenv has been created for this project yet!
Aborted!
Creating a virtualenv for this project...
Pipfile: /root/Pipfile
Using /usr/sbin/python3 (3.10.6) to create virtualenv...
⠦ Creating virtual environment...created virtual environment CPython3.10.6.final.0-64 in 335ms
  creator CPython3Posix(dest=/root/.local/share/virtualenvs/root-BuDEOXnJ, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/root/.local/share/virtualenv)
    added seed packages: pip==22.2.2, setuptools==65.3.0, wheel==0.37.1
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

✔ Successfully created virtual environment!
Virtualenv location: /root/.local/share/virtualenvs/root-BuDEOXnJ
Locking [packages] dependencies...
Locking [dev-packages] dependencies...
Building requirements...
Resolving dependencies...
⠼ Locking..✔ Success!
Warning: atomicwrites==1.4.1; sys_platform == 'win32' doesn't match your environment, its dependencies won't be resolved.
zipp==3.6.0; python_version < '3.10' doesn't match your environment, its dependencies won't be resolved.
Updated Pipfile.lock (7ff3cb)!
attemp 1:
attemp 2:
attemp 3:
attemp 4:
attemp 5:
attemp 6:
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
attemp 7:
<             "markers": "python_version >= '3.6'",
>             "markers": "python_full_version >= '3.6.0'",
<             "markers": "python_version >= '3.6'",
>             "markers": "python_full_version >= '3.6.0'",
<             "markers": "python_version >= '3.6'",
>             "markers": "python_full_version >= '3.6.0'",
<             "markers": "python_version >= '3.6'",
>             "markers": "python_full_version >= '3.6.0'",
<             "markers": "python_version >= '3.6'",
>             "markers": "python_full_version >= '3.6.0'",
<             "markers": "python_version >= '3.6'",
>             "markers": "python_full_version >= '3.6.0'",
<             "markers": "python_version >= '3.6'",
>             "markers": "python_full_version >= '3.6.0'",
<             "markers": "python_version >= '3.6'",
>             "markers": "python_full_version >= '3.6.0'",
<             "markers": "python_version >= '3.6'",
>             "markers": "python_full_version >= '3.6.0'",
attemp 8:
attemp 9:
attemp 10:
```
</details>
@dqkqd are you able to reproduce it with `pipenv==2022.9.2`?
Yes, it still happens. I created a docker repo for this.
```bash
docker run $(docker build --quiet https://github.com/dqkqd/pipenv-issues-4660.git)
```

results:
```
pipenv, version 2022.9.2
attemp 1: same
attemp 2: same
attemp 3: same
attemp 4: same
attemp 5: same
attemp 6: same
attemp 7: same
attemp 8: same
attemp 9: same
attemp 10:
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
```
Awesome test project @dqkqd !!!

On `2022.9.4` I am getting `same` each run:
```
matteius@matteius-VirtualBox:~/pipenv-triage/pipenv-4101$ docker run $(docker build --quiet https://github.com/dqkqd/pipenv-issues-4660.git)
pipenv, version 2022.9.4
attemp 1: same
attemp 2: same
attemp 3: same
attemp 4: same
attemp 5: same
attemp 6: same
attemp 7: same
attemp 8: same
attemp 9: same
attemp 10: same
attemp 11: same
attemp 12: same
```

I didn't realize it stops at 15 -- but those were all same too.
I got what you got too on `2022.9.2` -- so I think this is truly fixed now.   My belief is that the sorting helped a lot, but there was still an issue passing the constraints in as an environment variable and that was converted to `NamedTemporaryFile` in `2022.9.4` in order to solve an issue with windows environment variable lengths.
This issue still occurs. Should I change script to `whilte true` instead?

```
   ~ ❯ docker run $(docker build --quiet https://github.com/dqkqd/pipenv-issues-4660.git)         28s
pipenv, version 2022.9.4
attemp 1: same
attemp 2: same
attemp 3: same
attemp 4: same
attemp 5: same
attemp 6: same
attemp 7: same
attemp 8: same
attemp 9:
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
<             "markers": "python_full_version >= '3.6.0'",
>             "markers": "python_version >= '3.6'",
```

Resolving patch:
diff --git a/pipenv/vendor/requirementslib/__init__.py b/pipenv/vendor/requirementslib/__init__.py
--- a/pipenv/vendor/requirementslib/__init__.py
+++ b/pipenv/vendor/requirementslib/__init__.py
@@ -5,7 +5,7 @@
 from .models.pipfile import Pipfile
 from .models.requirements import Requirement
 
-__version__ = "2.0.2"
+__version__ = "2.0.3"
 
 
 logger = logging.getLogger(__name__)
diff --git a/pipenv/vendor/requirementslib/models/markers.py b/pipenv/vendor/requirementslib/models/markers.py
--- a/pipenv/vendor/requirementslib/models/markers.py
+++ b/pipenv/vendor/requirementslib/models/markers.py
@@ -2,7 +2,7 @@
 import operator
 import re
 from collections.abc import Mapping, Set
-from functools import lru_cache, reduce
+from functools import reduce
 
 import pipenv.vendor.attr as attr
 from pipenv.vendor.distlib import markers
@@ -116,7 +116,6 @@ def from_pipfile(cls, name, pipfile):
             return combined_marker
 
 
-@lru_cache(maxsize=1024)
 def _tuplize_version(version):
     # type: (STRING_TYPE) -> Union[Tuple[()], Tuple[int, ...], Tuple[int, int, str]]
     output = []
@@ -131,7 +130,6 @@ def _tuplize_version(version):
     return tuple(output)
 
 
-@lru_cache(maxsize=1024)
 def _format_version(version):
     # type: (Tuple[int, ...]) -> STRING_TYPE
     if not isinstance(version, str):
@@ -143,7 +141,6 @@ def _format_version(version):
 REPLACE_RANGES = {">": ">=", "<=": "<"}
 
 
-@lru_cache(maxsize=1024)
 def _format_pyspec(specifier):
     # type: (Union[STRING_TYPE, Specifier]) -> Specifier
     if isinstance(specifier, str):
@@ -179,7 +176,6 @@ def _format_pyspec(specifier):
     return specifier
 
 
-@lru_cache(maxsize=1024)
 def _get_specs(specset):
     if specset is None:
         return
@@ -263,7 +259,6 @@ def get_sorted_version_string(version_set):
 # TODO: Rename this to something meaningful
 # TODO: Add a deprecation decorator and deprecate this -- i'm sure it's used
 # in other libraries
-@lru_cache(maxsize=1024)
 def cleanup_pyspecs(specs, joiner="or"):
     specs = normalize_specifier_set(specs)
     # for != operator we want to group by version
@@ -309,7 +304,6 @@ def cleanup_pyspecs(specs, joiner="or"):
 
 
 # TODO: Rename this to something meaningful
-@lru_cache(maxsize=1024)
 def fix_version_tuple(version_tuple):
     # type: (Tuple[AnyStr, AnyStr]) -> Tuple[AnyStr, AnyStr]
     op, version = version_tuple
@@ -324,7 +318,6 @@ def fix_version_tuple(version_tuple):
 
 
 # TODO: Rename this to something meaningful, deprecate it (See prior function)
-@lru_cache(maxsize=128)
 def get_versions(specset, group_by_operator=True):
     # type: (Union[Set[Specifier], SpecifierSet], bool) -> List[Tuple[STRING_TYPE, STRING_TYPE]]
     specs = [_get_specs(x) for x in list(tuple(specset))]
@@ -484,7 +477,6 @@ def _markers_contains_key(markers, key):
     return False
 
 
-@lru_cache(maxsize=128)
 def get_contained_extras(marker):
     """Collect "extra == ..." operands from a marker.
 
@@ -498,7 +490,6 @@ def get_contained_extras(marker):
     return extras
 
 
-@lru_cache(maxsize=1024)
 def get_contained_pyversions(marker):
     """Collect all `python_version` operands from a marker."""
 
@@ -529,7 +520,6 @@ def get_contained_pyversions(marker):
     return versions
 
 
-@lru_cache(maxsize=128)
 def contains_extra(marker):
     """Check whether a marker contains an "extra == ..." operand."""
     if not marker:
@@ -538,7 +528,6 @@ def contains_extra(marker):
     return _markers_contains_extra(marker._markers)
 
 
-@lru_cache(maxsize=128)
 def contains_pyversion(marker):
     """Check whether a marker contains a python_version operand."""
 
@@ -710,7 +699,6 @@ def normalize_marker_str(marker):
     return marker_str.replace('"', "'")
 
 
-@lru_cache(maxsize=1024)
 def marker_from_specifier(spec):
     # type: (STRING_TYPE) -> Marker
     if not any(spec.startswith(k) for k in Specifier._operators.keys()):


Test patch: