Pipfile.lock creation does not expand environment variables

[dherault]

Issue description

When using an environment variable in a Pipfile, pipenv install is broken.
It seems that the environment variable does not get expanded during the Pipfile.lock creation.

Expected result

A created Pipfile.lock file

Actual result

An error, typically 401 Unauthorized from Gitlab when clonning repo during the Pipfile.lock creation

Steps to replicate

• Create a Pipfile that uses an environment variable. Typically with a private package from a custom git provider using a oauth secret as the environment variable.
• Run pipenv install with the environment variable sourced. The environment variable won't be expanded during Pipfile.lock creation.
• Notice that pipenv install --skip-lock works fine. The environment variable is expanded.

[uranusjr]

Please provide a reproducible Pipfile.

[clafoutis42]

@uranusjr we are making the effort of creating a dumb python repository for you to try
But if you want an example for you to try with a project of your own, you can get inspiration from this:

[packages]
click = "*"
kombu = "*"
"mypackage" = {editable = true, ref = "v0.0.1-rc9", git = "https://oauth2:${GITLAB_ACCESS_TOKEN}@gitlab.com/team/repository"}

The env var GITLAB_ACCESS_TOKEN is expanded while processing Pipfile, but it does not work while processing Pipflie.lock.

This worked with pipenv 2018.7.1 but does not work in any younger versions.

It is hard to provide you with a reproducible Pipfile as we require this to clone from our own servers using https without enabling any outside access.

[dherault]

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[dev-packages]

[packages]
flask = {git="https://${GITHUB}.com/pallets/flask.git"}

[requires]
python_version = "3.5"

Try GITHUB=github pipenv install --> does not work
Try GITHUB=github pipenv install --skip-lock --> works

[uranusjr]

I see the problem now… Pipfile only expands environment variables in the source section, not packages. I don’t think the --skip-lock invocation working is intended; it is likely a bug.

I am personally impartial on whether the expansion should extend to package entries, but there are a lot of implications there, you’ll need to submit a PEEP to kick off discussion.

Closing since this is more or less “working as intended”.