Fix a bug with enviroment variable injection to the git repo url

[ehengao]

Thank you for contributing to Pipenv!

The issue

Fix a enviroment injection issue when dealing with git repo url dependencies. The problem issued when pipenv trying to execute command similar to "git clone -q git+https://${USER}:${PASSWORD}/github.com" using python subprocess.Popen, the enviroment variable inside this command is not propely resolved.Which will cause a permission deny error or a repo not found error.

The fix

using os.path.expandvars(cmd-parts) before passing to subprocess.

The checklist

• Associated issue

#2635

• A news fragment:

news/2365.bugfix

[ehengao]

By any chance we can merge this?

[uranusjr]

I want to sit on this for a while. Generally a patch to vendor or patched is a last resort we want to avoid, since it may result in unintended subsequences.

[techalchemy]

Interesting issue -- I'm pretty sure we're going to un-vendor pip soon though so this might not be the best approach to solving it

[pcraciunoiu]

Is there a fix for installing private git repos with pipenv? I found this issue and I'm trying to avoid rolling a private pypi just for a repo or two...

[uranusjr]

One way is to use SSH, such as GitHub deploy keys.

[techalchemy]

Really anything that involves putting a password in a URI directly is a bad practice, and we've had similar versions of this proposed in the past and closed for various security related reasons that I can't completely recall. If someone can dig through the past issues on the topic it would be helpful