pipenv requirements should support the usage of pypi-mirror

[mtreffert-bhs]

pipenv requirements, that replaced pipenv lock --requirements... does not support the usage of pypi-mirrors anymore

Problem

Sometimes one needs to install packages from a different index than pypi.org

Desired Solution

A pypi mirror can be used with the pipenv requirements command as with other commands by supporting the --pypi-mirror flag and/or the environment variable PIPENV_PYPI_MIRROR

[matteius]

@mtreffert-bhs Could you provide an example of what the desired output looks like with a sample Pipfile.lock?

[mtreffert-bhs]

@matteius sure. Please find attached a minimal Pipfile.lock without any packages. I just added a ".txt" suffix, so that the file is accepted by the upload function. Pipfile.lock.txt

Desired Output without mirror:

pipenv requirements > requirements.txt should result in -i https://pypi.org/simple

Desired Output with mirror:

pipenv requirements --pypi-mirror https://example.com/simple > requirements.txt should result in -i https://example.com/simple

[dqkqd]

pipenv lock --requirements locking before printing out requirements, pypi-mirror could be checked. Since the new pipenv requirements doesn’t rely on locking, it just get ouput from Pipfile.lock, it might be dangerous to have pypi-mirror as an option. For example in case passed pypi-mirror isn’t usable.

[dqkqd]

I think there is an alternative solution that is :

pipenv lock --pypi-mirror should write pypi-mirror into Pipfile.lock.

Then pipenv requirement could use that mirror since it’s written in Pipfile.lock.

[mtreffert-bhs]

Writing the mirror into Pipfile.lock might not always be sufficiant, e. G. if the mirror-link contains a token. Then the Pipfile.lock cannot be added to version-control anymore without leaking sensitive information.

In my opinion it makes totally sense, that pipenv requirements just overrides the mirror if the parameter is passed or the environment-variable is set, no matter if it locks before or not. But maybe i miss something

[dqkqd]

pipenv requirements have to resolve dependencies to generate correctly requirements. It should either resolve by itself, or depend on Pipfile.lock, so locking before generate requirements makes sense.

Even if we pass in a mirror, I think it should not overrides without knowing if that mirror is valid or not.

And we could use environment variable inside Pipfile.lock, so no sensitive information would be leaked.

[mtreffert-bhs]

Actually the environment-variable is the solution that i currently use as a "workaround". I works, but i still think that overriding is legitimate, when it is explicitely passed through the parameter.

[matteius]

We cannot automatically allow credentials into the Pipfile and Pipfile lock for security reasons. See also #5298 because we just did something similar there to only pull in the index unredacted if the credentials are not revealed.

[matteius]

@mtreffert-bhs Can you explain how you use the environment-variable workaround so that I have a better understanding of the current behavior?