Repository: pypa/pipenv

Issue:
Using: keyrings.google-artifactregistry-auth pipenv update -d fails hard.
Be sure to check the existing issues (both open and closed!), and make sure you are running the latest version of Pipenv.

Check the [diagnose documentation](https://pipenv.pypa.io/en/latest/diagnose/) for common issues before posting! We may close your issue if it is very similar to one of them. Please be considerate, or be on your way.

Make sure to mention your debugging experience if the documented solution failed.


### Issue description

Google Artifact Repositories use keyrings with their own addon to make git and twine work perfectly, but when using pipenv it fails hard to a point where we cant use pipenv.

Note I also tried with 20.11.15 with same result

### Expected result

pipenv update -d should update dependencies and make an update Pipfile.lock

### Actual result

(applied_mapper)  klaus@new-server ~/src/applied_mapper master> pipenv update -d -v
Running $ pipenv lock then $ pipenv sync.
Locking [dev-packages] dependencies…
Building requirements...
Resolving dependencies...
⠧ Locking...
                          ROUND 1                           
✘ Locking Failed! 
Current constraints:
  aadomain (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 10))
  applied-core (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 14))
  applied-domain (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 9))
  geojson (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 13))
  keyring (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 7))
  keyrings.google-artifactregistry-auth (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 15))
  pbr (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 5))
  pylint (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 4))
  pytest (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 8))
  pytest-flake8 (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 6))
  python-dateutil (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 12))
  strenum (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 11))

Finding the best candidates:
  found candidate aadomain==1.4.42 (constraint was <any>)
Traceback (most recent call last):
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/utils.py", line 808, in resolve
    results = self.resolver.resolve(max_rounds=environments.PIPENV_MAX_ROUNDS)
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/patched/piptools/resolver.py", line 180, in resolve
    has_changed, best_matches = self._resolve_one_round()
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/patched/piptools/resolver.py", line 260, in _resolve_one_round
    best_matches = {self.get_best_match(ireq) for ireq in constraints}
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/patched/piptools/resolver.py", line 260, in <setcomp>
    best_matches = {self.get_best_match(ireq) for ireq in constraints}
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/patched/piptools/resolver.py", line 319, in get_best_match
    best_match = self.repository.find_best_match(
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 202, in find_best_match
    raise NoCandidateFound(ireq, all_candidates, self.finder)
pipenv.patched.piptools.exceptions.NoCandidateFound: Could not find a version that matches applied-core (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 14))
No versions found
Were https://europe-north1-pypi.pkg.dev/new-server/pypi/simple or https://legacy-pypi.appliedautonomy.no:8443/simple or https://pypi.org/simple reachable?

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/resolver.py", line 807, in <module>
    main()
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/resolver.py", line 802, in main
    _main(parsed.pre, parsed.clear, parsed.verbose, parsed.system, parsed.write,
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/resolver.py", line 785, in _main
    resolve_packages(pre, clear, verbose, system, write, requirements_dir, packages)
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/resolver.py", line 746, in resolve_packages
    results, resolver = resolve(
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/resolver.py", line 728, in resolve
    return resolve_deps(
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/utils.py", line 1378, in resolve_deps
    results, hashes, markers_lookup, resolver, skipped = actually_resolve_deps(
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/utils.py", line 1093, in actually_resolve_deps
    resolver.resolve()
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/utils.py", line 818, in resolve
    raise ResolutionFailure(message=str(e))
pipenv.exceptions.ResolutionFailure: ERROR: Could not find a version that matches applied-core (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 14))
No versions found
Were https://europe-north1-pypi.pkg.dev/new-server/pypi/simple or https://legacy-pypi.appliedautonomy.no:8443/simple or https://pypi.org/simple reachable?
ROUND 1                           
Current constraints:
  aadomain (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 10))
  applied-core (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 14))
  applied-domain (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 9))
  geojson (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 13))
  keyring (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 7))
  keyrings.google-artifactregistry-auth (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 15))
  pbr (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 5))
  pylint (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 4))
  pytest (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 8))
  pytest-flake8 (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 6))
  python-dateutil (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 12))
  strenum (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 11))

Finding the best candidates:
  found candidate aadomain==1.4.42 (constraint was <any>)
Traceback (most recent call last):
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/utils.py", line 808, in resolve
    results = self.resolver.resolve(max_rounds=environments.PIPENV_MAX_ROUNDS)
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/patched/piptools/resolver.py", line 180, in resolve
    has_changed, best_matches = self._resolve_one_round()
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/patched/piptools/resolver.py", line 260, in _resolve_one_round
    best_matches = {self.get_best_match(ireq) for ireq in constraints}
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/patched/piptools/resolver.py", line 260, in <setcomp>
    best_matches = {self.get_best_match(ireq) for ireq in constraints}
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/patched/piptools/resolver.py", line 319, in get_best_match
    best_match = self.repository.find_best_match(
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 202, in find_best_match
    raise NoCandidateFound(ireq, all_candidates, self.finder)
pipenv.patched.piptools.exceptions.NoCandidateFound: Could not find a version that matches applied-core (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 14))
No versions found
Were https://europe-north1-pypi.pkg.dev/new-server/pypi/simple or https://legacy-pypi.appliedautonomy.no:8443/simple or https://pypi.org/simple reachable?

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/resolver.py", line 807, in <module>
    main()
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/resolver.py", line 802, in main
    _main(parsed.pre, parsed.clear, parsed.verbose, parsed.system, parsed.write,
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/resolver.py", line 785, in _main
    resolve_packages(pre, clear, verbose, system, write, requirements_dir, packages)
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/resolver.py", line 746, in resolve_packages
    results, resolver = resolve(
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/resolver.py", line 728, in resolve
    return resolve_deps(
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/utils.py", line 1378, in resolve_deps
    results, hashes, markers_lookup, resolver, skipped = actually_resolve_deps(
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/utils.py", line 1093, in actually_resolve_deps
    resolver.resolve()
  File "/home/klaus/.local/lib/python3.8/site-packages/pipenv/utils.py", line 818, in resolve
    raise ResolutionFailure(message=str(e))
pipenv.exceptions.ResolutionFailure: ERROR: Could not find a version that matches applied-core (from -r /tmp/pipenvg2_zajwhrequirements/pipenv-2_qs5aav-constraints.txt (line 14))
No versions found
Were https://europe-north1-pypi.pkg.dev/new-server/pypi/simple or https://legacy-pypi.appliedautonomy.no:8443/simple or https://pypi.org/simple reachable?

### Steps to replicate

Provide the steps to replicate (which usually at least includes the commands and the Pipfile).

Its hard to replicate as you need alpha access to artifact repo pypi, but using a Pipfile like this:
[[source]]
name = "applied-backend"
url = "https://europe-north1-pypi.pkg.dev/new-server/pypi/simple"
verify_ssl = true

[[source]]
name = "applied"
url = "https://legacy-pypi.appliedautonomy.no:8443/simple"
verify_ssl = true

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]
keyring = "*"
"keyrings.google-artifactregistry-auth" = "*"
pytest = "*"
pytest-flake8 = "*"
pbr = "*"
pylint = "*"
StrEnum = "*"
python-dateutil = "*"
geojson = "*"
aadomain = "*"
applied-core = "*"
applied-domain = "*"

[packages]

[requires]
python_version = "3.9"
-------------------
then running pipenv update -d you will get the hard fail listed above. I do believe its connected to the keyring as it works as a charm in pip without any drama.

Please run `$ pipenv --support`, and paste the results here. Don't put backticks (`` ` ``) around it! The output already contains Markdown formatting.
<details><summary>$ pipenv --support</summary>

Pipenv version: `'2020.8.13'`

Pipenv location: `'/home/klaus/.local/lib/python3.8/site-packages/pipenv'`

Python location: `'/usr/bin/python3'`

Python installations found:

  - `3.9.0`: `/home/klaus/.local/share/virtualenvs/applied_mapper-zaPHu-S4/bin/python3.9`
  - `3.9.0`: `/home/klaus/.local/share/virtualenvs/applied_mapper-zaPHu-S4/bin/python3`
  - `3.9.0`: `/home/klaus/.local/share/virtualenvs/applied_mapper-zaPHu-S4/bin/python3.9`
  - `3.9.0`: `/home/klaus/.local/share/virtualenvs/applied_mapper-zaPHu-S4/bin/python3`
  - `3.9.0`: `/usr/bin/python3.9`
  - `3.9.0`: `/bin/python3.9`
  - `3.8.5`: `/usr/bin/python3.8`
  - `3.8.5`: `/usr/bin/python3`
  - `3.8.5`: `/bin/python3.8`
  - `3.8.5`: `/bin/python3`
  - `2.7.18`: `/usr/bin/python2`
  - `2.7.18`: `/usr/bin/python2.7`
  - `2.7.18`: `/bin/python2`
  - `2.7.18`: `/bin/python2.7`

PEP 508 Information:

```
{'implementation_name': 'cpython',
 'implementation_version': '3.8.5',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '5.4.0-73-generic',
 'platform_system': 'Linux',
 'platform_version': '#82-Ubuntu SMP Wed Apr 14 17:39:42 UTC 2021',
 'python_full_version': '3.8.5',
 'python_version': '3.8',
 'sys_platform': 'linux'}
```

System environment variables:

  - `GJS_DEBUG_TOPICS`
  - `SSH_AUTH_SOCK`
  - `SESSION_MANAGER`
  - `GNOME_TERMINAL_SCREEN`
  - `SSH_AGENT_PID`
  - `XDG_CURRENT_DESKTOP`
  - `LANG`
  - `LC_IDENTIFICATION`
  - `DEFAULTS_PATH`
  - `XDG_SESSION_CLASS`
  - `COLORTERM`
  - `LIBVIRT_DEFAULT_URI`
  - `GPG_AGENT_INFO`
  - `DESKTOP_SESSION`
  - `GJS_DEBUG_OUTPUT`
  - `XDG_MENU_PREFIX`
  - `USER`
  - `QT_IM_MODULE`
  - `LC_MEASUREMENT`
  - `VTE_VERSION`
  - `DBUS_SESSION_BUS_ADDRESS`
  - `PWD`
  - `LC_NUMERIC`
  - `GTK_MODULES`
  - `_`
  - `WINDOWPATH`
  - `XDG_SESSION_DESKTOP`
  - `JOURNAL_STREAM`
  - `QT_ACCESSIBILITY`
  - `HOME`
  - `GNOME_DESKTOP_SESSION_ID`
  - `MANAGERPID`
  - `LC_TIME`
  - `XDG_DATA_DIRS`
  - `GNOME_TERMINAL_SERVICE`
  - `LC_PAPER`
  - `LOGNAME`
  - `MANDATORY_PATH`
  - `XDG_RUNTIME_DIR`
  - `XDG_CONFIG_DIRS`
  - `XDG_SESSION_TYPE`
  - `XMODIFIERS`
  - `PATH`
  - `LC_TELEPHONE`
  - `LC_MONETARY`
  - `SHELL`
  - `GNOME_SHELL_SESSION_MODE`
  - `USERNAME`
  - `INVOCATION_ID`
  - `SHLVL`
  - `XAUTHORITY`
  - `LC_NAME`
  - `IM_CONFIG_PHASE`
  - `TERM`
  - `LC_ADDRESS`
  - `DISPLAY`
  - `GDMSESSION`
  - `ZSH`
  - `PAGER`
  - `LESS`
  - `LSCOLORS`
  - `LS_COLORS`
  - `CLOUDSDK_HOME`
  - `APPLIED_SCRIPT_HOME`
  - `GOOGLE_APPLICATION_CREDENTIALS`
  - `GOOGLE_ACCOUNT_SERVICE_FILE`
  - `NVM_DIR`
  - `NVM_CD_FLAGS`
  - `NVM_BIN`
  - `NVM_INC`
  - `pipfile_dir`
  - `PIP_DISABLE_PIP_VERSION_CHECK`
  - `PYTHONDONTWRITEBYTECODE`
  - `PIP_PYTHON_PATH`
  - `PIPENV_ACTIVE`
  - `VIRTUAL_ENV`
  - `PS1`
  - `PIP_SHIMS_BASE_MODULE`
  - `PYTHONFINDER_IGNORE_UNSUPPORTED`

Pipenv–specific environment variables:

 - `PIPENV_ACTIVE`: `1`

Debug–specific environment variables:

  - `PATH`: `/home/klaus/.local/share/virtualenvs/applied_mapper-zaPHu-S4/bin:/home/klaus/bin:/opt/ghc/bin:/home/klaus/.nvm/versions/node/v15.1.0/bin:/home/klaus/bin:/opt/ghc/bin:/home/klaus/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin`
  - `SHELL`: `/usr/bin/zsh`
  - `LANG`: `en_US.UTF-8`
  - `PWD`: `/home/klaus/src/applied_mapper`
  - `VIRTUAL_ENV`: `/home/klaus/.local/share/virtualenvs/applied_mapper-zaPHu-S4`


---------------------------

Contents of `Pipfile` ('/home/klaus/src/applied_mapper/Pipfile'):

```toml
[[source]]
name = "applied-backend"
url = "https://europe-north1-pypi.pkg.dev/new-server/pypi/simple"
verify_ssl = true

[[source]]
name = "applied"
url = "https://$legacy-pypi.appliedautonomy.no:8443/simple"
verify_ssl = true

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]
keyring = "*"
"keyrings.google-artifactregistry-auth" = "*"
pytest = "*"
pytest-flake8 = "*"
pbr = "*"
pylint = "*"
StrEnum = "*"
python-dateutil = "*"
geojson = "*"
aadomain = "*"
applied-core = "*"
applied-domain = "*"

[packages]

[requires]
python_version = "3.9"

```

</details>


Discussion:
I experienced the same issue and noticed that `pipenv` is actually able to download packages from Google Artifact Registry, and only failing when updating the lockfile. You can work around this by editing the lockfile file manually, or by doing something like this:
```
$ pip download --extra-index-url <URL_TO_ARTIFACT_REG> <YOUR_PACKAGE>
$ pipenv install *.whl
```
This will update the lockfile, but also modify your Pipfile to point towards local archives. Undo the changes to the Pipfile and it will work as expected.

I'm trying to figure out how to properly fix this, I'll reach out if I find anything.
I'm experiencing a similar issue and am also trying to find a solution. This workaround of downloading packages first and then installing them from local works, but is not so ideal
Its my dream to have pipenv+artifact-registry work nicely together (leveraging keychain for secure credential management).

Therin lies a world of rainbows and unicorns.

+1 on fixing this problem. I unfortunately lack the time to dig into this but if somebody could gat a fix in they would have my eternal gratitude.
This also fails for Azure DevOps Atifact Feeds with the `artifacts-keyring` backend, and I'm pretty sure everything that recommends authentication via a keyring backend when using the 2020 resolver. (I have not tried the legacy resolver yet.)
This is because pipenv.utils.resolver.Resolver's pip_options property sets no_input to true, which causes pip to disable keyring lookups (see `self.prompting` in auth.py in notpip's network module) since it is theoretically allowed for keyring backends to prompt the user.

I'm going to call it a night for today, but I wanted to share what I discovered so far.
I did not get as much sleep as I hoped, but at least I came up with a possible long term fix while lying awake: add a `--force-keyring` flag to pip to convince it to use keyring anyway potentially causing processes to hang if the user incorrectly configured keyring for that use case. (The recommanded way to use it would be by setting an environment variable or `pip config set`/manually editing a pip config file. Not to pass it via the cli.)

Any thoughts?
@Darsstar I see three options: 
* give the user the ability to change the value of `no_input` by changing the line to something like this `pip_options.no_input = self.project.settings.get("disable_pip_input", True)`. I can confirm this is working.
* patching pip (which is embedded) and changing the L248 of `auth.py` to allow bypassing it.
* use the below code snipped to fake the authentication and uninstall the keychain

```
echo -e "machine europe-west3-python.pkg.dev\nlogin oauth2accesstoken\npassword $(gcloud auth print-access-token)" > $HOME/.netrc
```

you have to replace `europe-west3-python.pkg.dev` with the registry you'd like to work with.
Any idea when this fix will be released? We're blocked from moving over to GCP artifact registry because of it.
@savitha-atg and cc: @allcloud-jonathan  I was hoping we could get some documentation added as part of the PR:  https://github.com/pypa/pipenv/pull/5036/files

Have you verified that PR is working for you?

Planning to do a pipenv release tonight, and so its possible we could merge it later today but like I said about the documentation.  Also since there are no tests for this change, that should be considered if its possible to add a test that would prevent future regression, even if it was a mock.patch test.  If we have to punt on the documentation and/or test for it, which seems less than ideal, lets at least ticket it before merging the other PR.
No, I haven't. I'm very new to `pipenv`. I'm assuming I'd have to build `pipenv` from sources to test the fix?
@savitha-atg Its relatively simpler than that with pip.  First you would `pip uninstall pipenv` version that you have -- then you would run:
`pip install git+https://github.com/pypa/pipenv.git@allcloud-jonathan:feature/no_input_flag`   

If you do the preferred user installs of pipenv (which requires having that location on your PATH) then you would just add the `--user` flag to that command.  Then you should be able to test the version with `pipenv --version` and test with the new option that has been added by adding it you your Pipfile.
So apparently I have not linked the PR I created for the Pip issue I did link. Let me rectify that: https://github.com/pypa/pip/pull/11029.
I wouldn't mind some people who want it to make themselves known.

In the unlikely(?) situation that patching the vendored Pip with those changes and adding a `--force-keyring` flag to Pipenv is acceptable as well I would be willing to implement and document that this evening. (CEST / UTC+02:00) (I would make Pipenv's `--force-keyring` set the `PIP_FORCE_KEYRING` environment variable of the subprocess set so the stringified True/False value)
I ran this slightly different command to install the fix:
`pip install git+https://github.com/allcloud-jonathan/pipenv.git@feature/no_input_flag --user`.

I've confirmed that I've the right version:
```
$ pipenv --version
pipenv, version 2022.3.29.dev0
```

Then, I modified my Pipfile like this:

```
[[source]]
name = "my-pypi"
url = "https://<my-artifact-registry>/simple"
verify_ssl = true

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]

[packages]
<my-package> = {disable_pip_input = false}

[requires]
python_version = "3.8.8"

[pipenv]
allow_prereleases = true
```

Is that right? I'm still running into failure to lock:

```
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
  Hint: try $ pipenv lock --pre if it is a pre-release dependency.
```

Thanks @Darsstar  -- My quick reaction is that is too big of a change for a pip vendoring patch when you already have a good level of buy in that this will be accepted into pip, which we would get through re-vendoring at that time.  This raises the question of does the current outstanding PR satisfy patching this issue in the interim?
@savitha-atg I think that `Pipfile` is not quite right.  Please try it like this:

```
[[source]]
name = "my-pypi"
url = "https://<my-artifact-registry>/simple"
verify_ssl = true

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]

[packages]
<my-package> = {}

[requires]
python_version = "3.8.8"

[pipenv]
allow_prereleases = true
disable_pip_input = false
```
> you already have a good level of buy in that this will be accepted into pip

Assuming that it will indeed gets accepted into pip, would you want pipenv to have a `--force-keyring` flag as well? If so I will start working on a that.
Ok, I've made the above change. I'm still running into locking issue:

```
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
  Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: No matching distribution found for pyarrow==3.0.0
```

I've confirmed that `pipenv install --skip-lock` works fine. 
@savitha-atg You are running into the new features of package index restrictions.  Long story short, because pypi is your second source its non default.   You'll have to pin a package one way or the other to an index with your setup, depending on the number of packages you need to pin is how I would pick my default.  So for example:

```
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[[source]]
name = "my-pypi"
url = "https://<my-artifact-registry>/simple"
verify_ssl = true

[dev-packages]

[packages]
<my-package> = {version: "*", index: "my-pypi"}

[requires]
python_version = "3.8.8"

[pipenv]
allow_prereleases = true
disable_pip_input = false
```

For more details there are some recently closed issues and the documentation was recently updated to be more helpful:  https://pipenv.pypa.io/en/latest/advanced/#specifying-package-indexes
@Darsstar Feel free to open a PR about it, I am admittedly a bit rusty on how the pip arguments get supported in pipenv, and I seem recall discussions on old issues about it being challenging to support all the arguments.  Perhaps there is a way though with environment variables to specify pip arguments such that we don't need to add an explicit flag within pipenv for it?  Sorry, I am a bit tied up at the moment to really research this further today but definitely see what you can figure out and it will get us thinking more about it. 
@matteius That worked! 

Would you be able to release this fix today? I'd rather install an official `pipenv`. Would really appreciate it! Thank you!
@matteius I'm having a similar issue to what savitha-atg is seeing.  We have packages that are only available in a private Google Artifact Registry server.  However, we're currently specifying our dependencies in a `setup.cfg` file rather than the Pipfile.  We do this to make sure the requirements are captured appropriately when we go to package up that module.  As such, our Pipfile packages section looks like 

```
[packages]
<this_library>= {editable = true, extras = ["testing", "dev"], path = "."}
jupyter = "*"
```

with all the dependencies for `this_library` specified in `setup.cfg`.  I did some googling, and couldn't find any way to specify the index in the setup.cfg file.  Is this something that's supported?  We want to be able to edit the package locally, which is why we have the `path = "."`.  Alternatively, if we're just setting up our repository in entirely the wrong way, I'm happy to be told so :)
@kylebluenote There is no current way to specify the index in the setup.cfg or pyproject.toml or setup.py -- as far as I know, it is only a pip and pipenv feature today to specify the indexes.   For your case the recommendation would be to mirror the pypi packages to your local pypi server and have that be the default index.  All packages that are unspecified try to resolve only to the default index.   We are working on a feature that would allow installation from multiple sources again as it was before since they have the hashes properly sources in the lock file already, but for locking resolution to work it needs to not guess what index to pull the package from.  
After some trial and error, I found that you can specify dependencies packaged through `setup.cfg` in your `Pipfile` as well. That would allow you to specify the index for those dependencies. For example: 

`setup.cfg:`
```
install_requires =
  my-library = x.y.z
```

`Pipfile:`
```
[packages]
my-library = {index = "my-pypi"}
my-application = ""
```

`pipenv install` then installs `my-library` at the pinned version, i.e. `x.y.z`. In addition, building and installing the `my-application` package installs `my-library` as intended.
Sharing an extra observation - `pipenv` doesn’t appear to install transitive dependencies. For example, if package `app1` depends on `lib1`, which in turn depends on `lib2`, when installing `app1`, it installs `lib1`, which is a declared dependency. But `lib2` doesn’t get installed. To work around that, I had to explicitly declare `lib2` as a dependency in `Pipfile`. Basically, all (direct and transitive dependencies) have to be declared in `Pipfile` for the dependency chain to be correctly installed. This isn't ideal, but since we only have a few packages, it's workable for now.
pipenv 2023.4.20 vendors pip 23.1. pip 23.1 contains https://github.com/pypa/pip/pull/11698.

While `disable_pip_input = false` no longer works, it doesn't need to.
https://pip.pypa.io/en/stable/topics/authentication/#using-keyring-as-a-command-line-application contains instructions for how to set up keyring so it can be used by pip 23.1.
The source url MUST contain a username. (https://dummyusername@example.com/pypi/simple for example)
Azure DevOps/artifacts-keyring users, [you MUST use `VssSessionToken` as the username](https://github.com/microsoft/artifacts-keyring/blob/97436d0b468aac7aa43d69a2b6bf33827e94edbd/src/artifacts_keyring/__init__.py#L71-L72).
I suspect Google Artifact users can use any value for the username you wish.

I hope this is helpfull to people.
@Darsstar's comment nudged me in the right direction (thanks !). As I mentionned in [this other issue](https://github.com/pypa/pipenv/issues/4074#issuecomment-1535990225) I face the same situation with Google Artifact and [the username must be set to `oauth2accesstoken`](https://github.com/GoogleCloudPlatform/artifact-registry-python-tools/blob/44f692b70771fcff40199170f7210a5373b72ccf/keyrings/gauth.py#L69).
Just to make it easier for future readers. This kind of a Pipfile works for me on a private Google artifact repository. You also need to have your authentication set up correctly.

```
[[source]]
url = "https://oauth2accesstoken@us-central1-python.pkg.dev/PROJECT_ID/REPOSITORY_NAME/simple"
verify_ssl = true
name = "private-artifacts"

[packages]
PRIVATE_LIBRARY_NAME = {version="==1.0.0", index="python-artifacts"}

[pipenv]
disable_pip_input = false
```

So basically two features are needed:
* The private URL needs to contain `oauth2accesstoken@`
* `disable_pip_input = false` must be present

I have pipenv version `2023.4.20`.
I'm trying to get a better understanding of how `pipenv` integrates with the keyring - I've got it working a little bit similarly to how kristjanveeve has it, but I've noticed some weird behavior:

My setup:

- I use `pyenv` and `pipx`.
- I installed `pipenv` using `pipx install pipenv`.

I have a project with a Pipfile that looks like this:

```
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[[source]]
url = "https://oauth2accesstoken@mygar/index/simple/"
verify_ssl = true
name = "gar"

[pipenv]
disable_pip_input = false

[packages]
...

[dev-packages]
...

[requires]
python_version = "3.11.3"
```

A few things I've noticed:

- `pipenv lock` seems to work for me, but only when I have `keyring` and `keyrings.google-artifactregistry-auth` installed in the *project* virtualenv.  I have tried these other combinations:
  - keyring pkgs installed in the `pipenv` virtualenv (managed by pipx) but not the project virtualenv.
  - keyring pkgs installed in neither virtualenv
  - keyring pkgs installed in both the `pipenv` and project virtualenvs.

The two configurations where the keyring packages aren't installed in the *project* virtualenv result in the following error when I attempt to run `pipenv lock`: `CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:Could not find a version that satisfies the requirement MY_INTERNAL_LIB (from versions: none)`.  I find the fact that it's using the project's virtualenv quite surprising, and I think clearly means that there's something I don't understand about how pipenv attempts package resolution...

Additionally, I've tested this on the following `pipenv` versions:

- 2023.3.20
- 2023.4.20
- 2023.4.29
- 2023.5.19

When I run on `2023.5.19`, I start getting the following error from the google artifact keyring ```
ERROR:keyring.backend:Error initializing plugin EntryPoint(name='Google Auth', value='keyrings.gauth', group='keyring.backends').
...
ModuleNotFoundError: No module named 'requests.packages.urllib3'; 'requests.packages' is not a package```.

I'm not totally sure if this is a pipenv bug, but I'm a little bit confused about where to start understanding this, since this is the keyring library version in my *project* virtualenv.

Lastly, I'm not entirely sure what Darsstar meant above, but

```
[pipenv]
disable_pip_input = false
```

does seem to still be necessary for me, in the configurations that work at all.

----

I think my overall question is: is there an "expected" usage pattern for keyring integration with pipenv for private package registries?  e.g. should the keyring packages be installed adjacent to pipenv, or inside of the project venv?  Should `disable_pip_input` be used or not?

I think with a better understanding of how I "should" use these, I can better hone in on what's actually going wrong in my environment.

Thanks!

> * but only when I have `keyring` and `keyrings.google-artifactregistry-auth` installed in the _project_ virtualenv

What does `pip config debug` say you set `global.keyring-provider` to? It should be `subprocess`.
What Pip version does gets installed when you run `pipenv install` in an empty directory? If below 23.1, run `virtualenv --upgrade-embed-wheels` and see if that helps?

Since you used Pipx to install pipenv Pipx's Pip version should now be 23.1 or higher, but tools like pyprojectx probably won't work yet untill a Python version comes out that ships a .whl in the ensurepip module of version 23.1 or higher and you start using that version exclusively.

> e.g. should the keyring packages be installed adjacent to pipenv, or inside of the project venv? Should `disable_pip_input` be used or not?

Depends on the `keyring-provider` you configured. If `import`, then yes. If `subprocess`, then no. I use `subprocess`.

Configure Pip so that a venv created with `virtualenv dummy` works, and Pipenv's vendored Pip should work...

> is there an "expected" usage pattern for keyring integration with pipenv for private package registries?

Configure Pip so that a venv created with `virtualenv dummy` works, and Pipenv's vendored Pip should work...
Python's `venv` module has no way to update the embeded `pip-<snip>.whl`, so you'll have to use `virtualenv` to create the venv or upgrade the venv's Pip before testing in earnest.
I believe it is possible to configure virtualenv to always use a specific Pip version, so run `virtualenv --help` and see what the default for `--pip` is if you start to get paranoid.

Thanks @justin-yan your comment was really insightful:
> pipenv lock seems to work for me, but only when I have keyring and keyrings.google-artifactregistry-auth installed in the project virtualenv.

That was a missing piece for me to get up an running to debug these issues fruther.

```
pipenv run pip install keyring
pipenv run pip install keyrings.google-artifactregistry-auth
```

It seems the next issue is that in `2023.5.19` I had to reintroduce this:  https://github.com/pypa/pipenv/blob/main/pipenv/__init__.py#L24

Which has the effect of causing the pip requests to be the first one that is imported, and it does not have a `requests.packages.urllib3`  -- when I change these lines locally to .append() instead of insert in the front, it has the effect of allowing the requests installed in the virtualenv to be found first, which has the required imports for keyring -- keyrings.google-artifactregistry-auth.   The disadvantage to making that change is something in the virtualenv that could be older than whats in the vendor packages could take precedence and cause a different side effect in pipenv.  I'll have to think more about how to move forward with this.

Resolving patch:
diff --git a/pipenv/__init__.py b/pipenv/__init__.py
--- a/pipenv/__init__.py
+++ b/pipenv/__init__.py
@@ -1,27 +1,15 @@
-# |~~\'    |~~
-# |__/||~~\|--|/~\\  /
-# |   ||__/|__|   |\/
-#      |
-
 import os
-import sys
 import warnings
 
-from pipenv.__version__ import __version__  # noqa
+from pipenv.cli import cli
 from pipenv.patched.pip._vendor.urllib3.exceptions import DependencyWarning
 
 warnings.filterwarnings("ignore", category=DependencyWarning)
 warnings.filterwarnings("ignore", category=ResourceWarning)
 warnings.filterwarnings("ignore", category=UserWarning)
-PIPENV_ROOT = os.path.abspath(os.path.dirname(os.path.realpath(__file__)))
-PIPENV_VENDOR = os.sep.join([PIPENV_ROOT, "vendor"])
-PIP_VENDOR = os.sep.join([PIPENV_ROOT, "patched", "pip", "_vendor"])
 
 # Load patched pip instead of system pip
 os.environ["PIP_DISABLE_PIP_VERSION_CHECK"] = "1"
-sys.path.insert(0, PIPENV_ROOT)
-sys.path.insert(0, PIPENV_VENDOR)
-sys.path.insert(0, PIP_VENDOR)
 
 if os.name == "nt":
     from pipenv.vendor import colorama
@@ -30,8 +18,6 @@
     if not os.getenv("NO_COLOR") or no_color:
         colorama.just_fix_windows_console()
 
-from . import resolver  # noqa: F401,E402
-from .cli import cli  # noqa: E402
 
 if __name__ == "__main__":
     cli()
diff --git a/pipenv/cli/command.py b/pipenv/cli/command.py
--- a/pipenv/cli/command.py
+++ b/pipenv/cli/command.py
@@ -668,6 +668,7 @@ def run_open(state, module, *args, **kwargs):
 @system_option
 @option("--bare", is_flag=True, default=False, help="Minimal output.")
 @sync_options
+@site_packages_option
 @pass_state
 @pass_context
 def sync(ctx, state, bare=False, user=False, unused=False, **kwargs):
@@ -687,6 +688,7 @@ def sync(ctx, state, bare=False, user=False, unused=False, **kwargs):
         system=state.system,
         extra_pip_args=state.installstate.extra_pip_args,
         categories=state.installstate.categories,
+        site_packages=state.site_packages,
     )
     if retcode:
         ctx.abort()
diff --git a/pipenv/routines/install.py b/pipenv/routines/install.py
--- a/pipenv/routines/install.py
+++ b/pipenv/routines/install.py
@@ -354,6 +354,7 @@ def do_sync(
     deploy=False,
     extra_pip_args=None,
     categories=None,
+    site_packages=False,
 ):
     # The lock file needs to exist because sync won't write to it.
     if not project.lockfile_exists:
@@ -368,6 +369,7 @@ def do_sync(
         deploy=deploy,
         pypi_mirror=pypi_mirror,
         clear=clear,
+        site_packages=site_packages,
     )
 
     # Install everything.


Test patch: