pipenv icon indicating copy to clipboard operation
pipenv copied to clipboard

Published 20 hours ago • verified publisher icon pypa

Pipenv lock changes markers in a non deterministic way

Open matpompili opened this issue 3 years ago • 24 comments

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 --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'.

matpompili avatar Mar 27 '21 13:03 matpompili

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:

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

matpompili avatar Mar 27 '21 14:03 matpompili

Hi, I am also getting this result, but on every pipenv lock call. It just goes back and forth between '4' and '4.0'.

jshwi avatar Aug 12 '21 05:08 jshwi

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

 - 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 avatar Aug 25 '21 11:08 matpompili

@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.

matteius avatar Mar 12 '22 10:03 matteius

Still having the same behaviour after upgrading to pip 22.0.4. Using pipenv 2022.5.2:

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?

porn avatar May 18 '22 07:05 porn

Still having the same behaviour after upgrading to pip 22.0.4. Using pipenv 2022.5.2:

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.

gitpushdashf avatar May 18 '22 17:05 gitpushdashf

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.

matteius avatar May 18 '22 17:05 matteius

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).

matteius avatar Jul 28 '22 14:07 matteius

Hey @matteius ,

using pip 22.2.1 and pipenv 2022.7.24 keeps altering python_full_version and python_version randomly:

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": {

porn avatar Aug 01 '22 11:08 porn

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.

matteius avatar Aug 01 '22 13:08 matteius

Still having this on the latest pipenv which should have the fix, right?

gitpushdashf avatar Aug 08 '22 21:08 gitpushdashf

@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.

matteius avatar Aug 08 '22 22:08 matteius

Interesting! I get the inconsistency between runs, however, on the same system. Could that happen from mismatched pip versions, locally?

gitpushdashf avatar Aug 09 '22 15:08 gitpushdashf

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 avatar Aug 28 '22 08:08 cclauss

@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.

matteius avatar Aug 28 '22 11:08 matteius

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 avatar Aug 31 '22 00:08 gitpushdashf

@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?

matteius avatar Sep 01 '22 11:09 matteius

I could reproduce this.

Pipfile 
[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
script.sh 
#!/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
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"]
Result 
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:

dqkqd avatar Sep 02 '22 01:09 dqkqd

@dqkqd are you able to reproduce it with pipenv==2022.9.2?

matteius avatar Sep 02 '22 14:09 matteius

Yes, it still happens. I created a docker repo for this.

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'",

dqkqd avatar Sep 02 '22 14:09 dqkqd

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.

matteius avatar Sep 08 '22 06:09 matteius

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.

matteius avatar Sep 08 '22 06:09 matteius

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'",

dqkqd avatar Sep 08 '22 10:09 dqkqd

Perhaps too early to tell, but I maybe am onto something about this issue -- I removed the lru_cache decorators around the marker generation in requirementslib in this PR: https://github.com/pypa/pipenv/pull/5373

I updated @dqkqd example Dockerfile to install this branch, and ran it three times without issue:

matteius@matteius-VirtualBox:~/pipenv-triage/pipenv-issues-4660$ vim Dockerfile 
matteius@matteius-VirtualBox:~/pipenv-triage/pipenv-issues-4660$ docker build .
Sending build context to Docker daemon  62.46kB
Step 1/7 : FROM archlinux
 ---> 546c416f6b9d
Step 2/7 : RUN pacman -Syu diffutils python3 python-pip git --noconfirm &> /dev/null
 ---> Using cache
 ---> 41664f828c96
Step 3/7 : RUN python -m pip install "git+https://github.com/pypa/pipenv.git@marker-determinism#egg=pipenv"  &> /dev/null
 ---> Running in 22c5f25c4438
Removing intermediate container 22c5f25c4438
 ---> c02c60d77ad3
Step 4/7 : WORKDIR /root
 ---> Running in d0e82db1ef6c
Removing intermediate container d0e82db1ef6c
 ---> 3333d4a56886
Step 5/7 : COPY Pipfile .
 ---> 42d116d6b71d
Step 6/7 : COPY script.sh .
 ---> f1089d4652f4
Step 7/7 : ENTRYPOINT ["./script.sh"]
 ---> Running in c0674607980b
Removing intermediate container c0674607980b
 ---> 964680f6585f
Successfully built 964680f6585f
matteius@matteius-VirtualBox:~/pipenv-triage/pipenv-issues-4660$ docker run 964680f6585f
pipenv, version 2022.9.22.dev0
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
attemp 13: same
attemp 14: same
attemp 15: same
matteius@matteius-VirtualBox:~/pipenv-triage/pipenv-issues-4660$ docker run 964680f6585f
pipenv, version 2022.9.22.dev0
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
attemp 13: same
attemp 14: same
attemp 15: same
matteius@matteius-VirtualBox:~/pipenv-triage/pipenv-issues-4660$ docker run 964680f6585f
pipenv, version 2022.9.22.dev0
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
attemp 13: same
attemp 14: same
attemp 15: same
matteius@matteius-VirtualBox:~/pipenv-triage/pipenv-issues-4660$ docker run 964680f6585f
pipenv, version 2022.9.22.dev0
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
attemp 13: same
attemp 14: same
attemp 15: same
matteius@matteius-VirtualBox:~/pipenv-triage/pipenv-issues-4660$ cat Dockerfile 
FROM archlinux

RUN pacman -Syu diffutils python3 python-pip git --noconfirm &> /dev/null
RUN python -m pip install "git+https://github.com/pypa/pipenv.git@marker-determinism#egg=pipenv"  &> /dev/null

WORKDIR /root
COPY Pipfile .
COPY script.sh .

ENTRYPOINT ["./script.sh"]

I also relocked pipenv 4 times and the markers only changed the first time suggesting that the branch that removes lru_cache makes it determinisitic. 🤞

matteius avatar Sep 22 '22 08:09 matteius

This is great, thank you!

gitpushdashf avatar Sep 27 '22 21:09 gitpushdashf