Allow pipenv sync to try alternative pip index urls as long as hashes match.

[mungojam]

Is your feature request related to a problem? Please describe.

As discussed on #5029 (comment), we would like the ability restored to run pipenv sync against multiple potential pip package indexes. This is to enable us to move builds between different environments which have access to different packages sources (for example pypi vs. an internal pypi cache vs. GitHub packages once they add pip support).

Describe alternatives you've considered

My alternative is to rewrite the pipfile.lock with the alternative locations before running pipenv sync, depending on the environment which is a big hack.

Other context

#5039 has been kindly created by @matteius to cover this, so I will try that out

[matteius]

@mungojam Any updates on your end if that branch is effective? Still want to settled in on the option name and get it added to the documentation once we know that works. I don't have a great unit test lined up either. Will want to get this queued up soon because we are pending the dropping of python 3.6 and the vendoring of pip 22.0.4 to try and get another release out for your use case before then. Our target for that other work is end of April.

[mungojam]

@mungojam Any updates on your end if that branch is effective? Still want to settled in on the option name and get it added to the documentation once we know that works. I don't have a great unit test lined up either. Will want to get this queued up soon because we are pending the dropping of python 3.6 and the vendoring of pip 22.0.4 to try and get another release out for your use case before then. Our target for that other work is end of April.

I got part way through testing it, I'll try and get it finished today

[mungojam]

@matteius this doesn't need to be tied to removing 3.6 support. Feel free to push on with that. In trying to test this one, I'm hitting an unrelated pip error which I also hit from my global python installation now:

File "C:\Users\adams6m\AppData\Roaming\Python\Python36\site-packages\pip_vendor\urllib3\util\ssl_.py", line 453, in ssl_wrap_socket
ssl_sock = ssl_wrap_socket_impl(sock, context, tls_in_tls)
File "C:\Users\adams6m\AppData\Roaming\Python\Python36\site-packages\pip_vendor\urllib3\util\ssl.py", line 495, in _ssl_wrap_socket_impl
return ssl_context.wrap_socket(sock)
File "C:\ProgramData\Anaconda3\lib\ssl.py", line 401, in wrap_socket
_context=self, _session=session)
File "C:\ProgramData\Anaconda3\lib\ssl.py", line 764, in init
raise ValueError("check_hostname requires server_hostname")
ValueError: check_hostname requires server_hostname

I'll need to sort out my machine before I can test the PR, and I won't have time to do that until next week probably. I may just switch focus to enabling later versions of python and then I can test this PR without hitting these other 3.6 related niggles.

[matteius]

Awesome, thanks @mungojam for that update! I was worried about dropping 3.6 support since I knew you requested both things, but this is helpful that dropping 3.6 won't be a blocker for you on this one.