Is `pipenv lock --requirements` correct?

[notEvil]

Maybe I misunderstand the concept of Pipfile.lock and pipenv lock, but as far as I see, pipenv lock updates outdated packages in Pipfile.lock. However, I would assume that during deployment we would want to use packages of a previous freeze (not freeze during deployment). I'm also not sure if pipenv lock --keep-outdated would do the right thing.

[dschep]

Works as expected AFAICT

$ pipenv lock -r -d|grep awscli
awscli==1.15.27
$ grep awscli Pipfile.lock -A 6
        "awscli": {
            "hashes": [
                "sha256:0c23bcda1086a94f2ebdfa6b23cde026fab1a1635f49c4665b66eb5cf20ea0c9",
                "sha256:67efe642acbf3d32e11380c3dd82f543de7a7afe87e76645faf27299b0ec9438"
            ],
            "index": "pypi",
            "version": "==1.15.27"

and the current version of awscli is 1.15.28 so you can see it's outputting the same versions as are in Pipfile.lock.

[notEvil]

well, I'm still not sure if I understand correctly. I just tried the following:

• pipenv install awscli==1.15.27
• manually change pinned version in Pipfile to *
• pipenv lock

It should resemble the sequence

• pipenv install awscli; latest version is 1.15.27
• 1.15.28 is uploaded to PyPI
• pipenv lock

After that, Pipfile.lock contains version 1.15.28. What if I want to use exactly the same versions as defined in Pipfile.lock for deployment, similar to pipenv sync? Isn't that what we usually want?

[dschep]

I'm not sure I follow. What I'm saying is that pipenv lock -r doesn't update Pipenv.lock or generate a requirements.txt from Pipfile. It outputs requirements.txt generated from Pipfile.lock without updating it. In my above example, the Pipfile.lock contained 1.15.27 and the outputed requirements did too. pipenv lock with out the -r updates awscli in the Pipfile.lock to 1.15.28.

edit: and Pipfile contained awscli = "*"

[notEvil]

I can't reproduce the behaviour you describe. When I run pipenv lock -r (version 2018.05.18, Pipfile exists and contains awscli = "*", Pipfile.lock exists and contains "version": "==1.15.27", environment doesn't exist yet) I get

Pipfile.lock (882832) out of date, updating to (e2b23a)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…

Of course if you pin the version from the start, its written to Pipfile and therefore won't change.

[dschep]

Huh.. ok I created a new pipenv project and was able to reproduce the behavior you're seeing, no clue why my other project doesn't. pipenv lock --keep-outdated -r does seem to have the right behavior. I'll update this plugin's usage to add the --keep-outdated

Thanks for catching this!