requirements command improvements, fixes issue 5755.

[matteius]

Fixes #5755

The issue

The requirements command should have it all it needs from the lock file, but its re-using a requirementslib method that installs the requirements, which was a regression for the requirements command when we released requirementslib==3.0.0

The fix

Provide our own method and relocate the requirements command logic to the routines module.

The checklist

• Associated issue
• A news fragment in the news/ directory to describe this fix with the extension .bugfix.rst, .feature.rst, .behavior.rst, .doc.rst. .vendor.rst. or .trivial.rst (this will appear in the release changelog). Use semantic line breaks and name the file after the issue number or the PR #.

[mgmarino]

In the test Pipfile.lock in #5755, this generates the following:

-i https://pypi.org/simple
cffi==1.15.1
cryptography==41.0.1; python_version >= '3.7'
pycparser==2.21
"pyjwt[crypto] @ --editable git+https://[email protected]/jpadilla/pyjwt.git@7665aa625506a11bae50b56d3e04413a3dc6fdf8"

Definitely no network calls, but this fails to install with:

➜  pipenv_test pip --version
pip 23.0.1 from /xxx/mgmarino/.pyenv/versions/3.9.16/lib/python3.9/site-packages/pip (python 3.9)
➜  pipenv_test pip install -r requirements.txt
ERROR: Invalid requirement: "pyjwt[crypto] @ --editable git+https://[email protected]/jpadilla/pyjwt.git@7665aa625506a11bae50b56d3e04413a3dc6fdf8"
Could not split options: --editable git+https://[email protected]/jpadilla/pyjwt.git@7665aa625506a11bae50b56d3e04413a3dc6fdf8"

[matteius]

@mgmarino Just pushed a fix for that -- thanks for catching it.

[mgmarino]

Ok, two more comments:

• the enclosing "" are causing problems. i.e. instead of:

"pyjwt[crypto] @ git+https://[email protected]/jpadilla/pyjwt.git@7665aa625506a11bae50b56d3e04413a3dc6fdf8"

needs to be:

pyjwt[crypto] @ git+https://[email protected]/jpadilla/pyjwt.git@7665aa625506a11bae50b56d3e04413a3dc6fdf8

.

• Also, this doesn't seem to respect the scheme, i.e. if ssh:// is listed it still gets exported as https://. This is important for us because we have ssh authentication to github. Example:

In Pipfile.lock:

        "our-module": {
            "editable": true,
            "extras": [
                "extra_one",
                "extra_two"
            ],
            "git": "ssh://[email protected]/company/our-module.git",
            "ref": "818b13269eac0753d0029ffe496f3a6c08614bf0"
        },

is exported as

our-module[extra_one,extra_two] @ git+https://[email protected]/company/our-module.git@818b13269eac0753d0029ffe496f3a6c08614bf0

instead of:

our-module[extra_one,extra_two] @ git+ssh://[email protected]/company/our-module.git@818b13269eac0753d0029ffe496f3a6c08614bf0

[mgmarino]

lgtm, works for the simple test case in #5755 and our "real" cases. My last suggestion should get the tests working again, I think there was only one failure. I will probably add some additional test cases, but we can do that in another PR. :-)

[matteius]

Actually I should probably fix those tests and not have the space after the semi-colon, since that's technically more correct. We added the space a while back because of some weird side effect with the test framework hypothesis and upgrading pyparsing in requirementslib that was somehow solved by adding the space, but since this command is isolated, we should be more correct and fix the test assumptions.

[mgmarino]

Thanks, @matteius!