Pipenv install hangs, simply by adding private repository

[Overdrivr]

I've recently added a private repository to Pipfile.

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

[[source]]
url = "https://pypi.****.io/${AUTH}/***/"
verify_ssl = true
name = "mypypi"

[packages]
...

It's all I've done. I did not add any private packages. Just setting the private repo.

Issue description

After adding the private repository, the following command

pipenv install --dev

hangs in CI environment (Appveyor). The install process timeouts after 1 hour. Without adding the private source, it takes a couple of minutes.
It does not hang in Docker-based CI, nor on my Windows 10 machine.

Expected result

I expect it not to hang.

Actual result

$ "C:\\***\\pip.exe" install   --verbose  --no-deps  -r "C:\\***\\1\\pipenv-x1ion6s4-requirements\\pipenv-hja6lxq6-requirement.txt" --require-hashes -i https://pypi.python.org/simple --extra-index-url https://pypi.***.io/***/***/ --exists-action w
Installing 'networkx==2.1 --hash=sha256:64272ca418972b70a196cb15d9c85a5a6041f09a2f32e0d30c0255f25d458bb1'
$ "C:\\***\\pip.exe" install   --verbose  --no-deps  -r "C:\\***\\1\\pipenv-x1ion6s4-requirements\\pipenv-s7weu7a0-requirement.txt" --require-hashes -i https://pypi.python.org/simple --extra-index-url https://pypi.***.io/***/***/ --exists-action w
Installing 'nose==1.3.7 --hash=sha256:9ff7c6cc443f8c51994b34a667bbcf45afd6d945be7477b52e97516fd17c53ac --hash=sha256:dadcddc0aefbf99eea214e0f1232b94f2fa9bd98fa8353711dacb112bfcbbb2a --hash=sha256:f1bffef9cbc82628f6e7d7b40d7e255aefaa1adb6a1b1d26c69a8b79e6208a98'
$ "C:\\***\\pip.exe" install   --verbose  --no-deps  -r "C:\\***\\1\\pipenv-x1ion6s4-requirements\\pipenv-jqcm4anq-requirement.txt" --require-hashes -i https://pypi.python.org/simple --extra-index-url https://pypi.***.io/***/***/ --exists-action w

It just freezes at this one last line without explanation. Is there a way to know which package it's currently trying to install ?

My tools are up-to-date (Python 3.6.6 64 bits, pip 18.0, Pipenv 2018.7.1)

python -V
Python 3.6.6
pip -V
pip 18.0 from c:\python36-x64\lib\site-packages\pip (python 3.6)
pip install pipenv
Collecting pipenv
  Downloading https://files.pythonhosted.org/packages/eb/64/9b2747d54f2008ac3dfe86c0b1c8ec126042726fd8a540d5208d26732701/pipenv-2018.7.1-py3-none-any.whl (5.0MB)

Steps to replicate

1. Add a private repository to a Pipfile
2. Add some official Pypi dependencies
3. Run pipenv install --dev inside appveyor CI

The problem does not seem due to Appveyor, because I have configured another repository with Appveyor + pipenv + private repository without issue.

• Any idea of what is going on here ?
• Any idea of how I can get additional information for debugging ?
• BTW, why is pipenv passing --extra-index-url flag to pip all the time ? Is it not considering that all package that don't specify a particular repository inside the Pipfile should be hosted on canonical pypi, therefore not needing the flag ?

Thank you for your help, let me know if there's something I can do to help you best.

[Overdrivr]

I have conducted further debugging by comparing with my other repo, and it turns out the only difference is the URL of the repository:

• In the repo where pipenv install hangs, the url is url = "https://pypi.***.io/${AUTH}/***/"
• in the repo where it works, the url is url = "https://${AUTH}@pypi.***.io/***/"

As soon as I switched to the second format, pipenv install performed correctly.

[techalchemy]

I believe there is a considerable amount of logic driving how url-based authentication is handled in most of the tooling around this, not just ours. You will likely always need the second format.

BTW, why is pipenv passing --extra-index-url flag to pip all the time ?

We pass this flag if you specify more than one repository, because often people have a local package but not all of its dependencies and those rely on --extra-index-url to pass the additional sources in order to resolve.

Is it not considering that all package that don't specify a particular repository inside the Pipfile should be hosted on canonical pypi, therefore not needing the flag ?

This isn't how pipenv works. If a package doesn't specify an index argument, by default pipenv will try to resolve using the first index in the pipfile first. Many users of pipenv never actually use the canonical PyPI, and we make no runtime assumptions that they should be doing so.

Hope this helps!