[idea] Support env variable expansion

[jakekdodd]

I think support for environment variable expansion in Pipfiles would be a nice middle ground between a spec that's an executable, and one that's a plain ol' flat file (as it is now). I'm already running into issues and frustrations with Pipfile-based projects due to the spec's completely static nature.

One objection I can anticipate is that environment variable expansion is not within the TOML spec. However, support for expansion at the TOML implementation/library/application layer is exactly the approach suggested by Tom himself.

I'm conscious of the goal to keep the spec minimal and bloat-free—but I think this is an addition seriously worth considering.

[AdrienLemaire]

Isn't that supported in 04c2616 ? I'm not sure to understand what you mean by "env variable expansion".

What I'd like to see implemented though, is support for default values when the env var isn't defined. My use case is defining a custom host for a github private repository when pipenv installing from docker (for it to use the proper ssh key), while using the default github.com host when pipenv installing from my host.
Something like:

[packages]
project-common = {editable = true, ref = "v1.3", git = "ssh://git@${GITHUB_HOST:-github.com}/org/project-common.git"}

Right now, I have to force the env var from my host as follow:

$ GITHUB_HOST=github.com pipenv install

[jakekdodd]

@Fandekasp "variable expansion" is just another way of saying parameter expansion, which is exactly what you're describing.

This issue was opened last November before 04c2616 was committed. That addresses simple environment variable substitution, which should be sufficient for the vast majority of cases, including yours. Performing environment variable expansion in the parent process is idiomatic, and arguably preferable to doing so within the Python process, so I'm closing this issue.