internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: pypa/pipenv

Issue:
Option to override pip's --exists-action, or PIP_EXISTS_ACTION
Hello,

I'm trying to find a way to specify `--exists-action` for pip install command, but it seems there's no way to override it.

Here:  https://github.com/pypa/pipenv/blob/master/pipenv/core.py#L1506 you force `"PIP_EXISTS_ACTION": vistir.misc.fs_str("w")`

I need a way to set either `PIP_EXISTS_ACTION=i` or `--exists-action=i` (ignore a package if it's already installed)
This would make installation really really (really) fast, if the virtual environment exists.

We need this because we cache and restore `.venv`, and this option would make CI much faster :) 


Thanks


Discussion:

Resolving patch:
diff --git a/pipenv/core.py b/pipenv/core.py
--- a/pipenv/core.py
+++ b/pipenv/core.py
@@ -26,7 +26,7 @@
     PIPENV_CACHE_DIR, PIPENV_COLORBLIND, PIPENV_DEFAULT_PYTHON_VERSION,
     PIPENV_DONT_USE_PYENV, PIPENV_HIDE_EMOJIS, PIPENV_MAX_SUBPROCESS,
     PIPENV_PYUP_API_KEY, PIPENV_SHELL_FANCY, PIPENV_SKIP_VALIDATION,
-    PIPENV_YES, SESSION_IS_INTERACTIVE
+    PIPENV_YES, SESSION_IS_INTERACTIVE, PIP_EXISTS_ACTION
 )
 from .project import Project, SourceNotFound
 from .utils import (
@@ -1513,7 +1513,7 @@ def pip_install(
         "PIP_DESTINATION_DIR": vistir.misc.fs_str(
             cache_dir.joinpath("pkgs").as_posix()
         ),
-        "PIP_EXISTS_ACTION": vistir.misc.fs_str("w"),
+        "PIP_EXISTS_ACTION": vistir.misc.fs_str(PIP_EXISTS_ACTION or "w"),
         "PATH": vistir.misc.fs_str(os.environ.get("PATH")),
     }
     if src:
diff --git a/pipenv/environments.py b/pipenv/environments.py
--- a/pipenv/environments.py
+++ b/pipenv/environments.py
@@ -234,6 +234,12 @@ def _is_env_truthy(name):
 NOTE: This only affects the ``install`` and ``uninstall`` commands.
 """
 
+PIP_EXISTS_ACTION = os.environ.get("PIP_EXISTS_ACTION", "w")
+"""Specifies the value for pip's --exists-action option
+
+Defaullts to (w)ipe
+"""
+
 PIPENV_RESOLVE_VCS = _is_env_truthy(os.environ.get("PIPENV_RESOLVE_VCS", 'true'))
 """Tells Pipenv whether to resolve all VCS dependencies in full.
 
@@ -242,7 +248,6 @@ def _is_env_truthy(name):
 approach, you may set this to '0', 'off', or 'false'.
 """
 
-
 PIPENV_PYUP_API_KEY = os.environ.get(
     "PIPENV_PYUP_API_KEY", "1ab8d58f-5122e025-83674263-bc1e79e0"
 )


Test patch:
Repository: pypa/pipenv

Issue:
pipenv check --system finds wrong python ver yielding `JSONDecodeError`
if you run `pipenv check --system` on a system which only has `python3` and not `python` binary, you'll get a `JSONDecodeError` due to an empty response from `which -a python`.  Instead with `--system` it should just use `sys.executable`


Discussion:

Resolving patch:
diff --git a/pipenv/core.py b/pipenv/core.py
--- a/pipenv/core.py
+++ b/pipenv/core.py
@@ -2578,8 +2578,9 @@ def do_check(
     args=None,
     pypi_mirror=None,
 ):
-    from .environments import is_verbose
     from pipenv.vendor.vistir.compat import JSONDecodeError
+    from pipenv.vendor.first import first
+
     if not system:
         # Ensure that virtualenv is available.
         ensure_project(
@@ -2618,7 +2619,10 @@ def do_check(
     if not system:
         python = which("python")
     else:
-        python = system_which("python")
+        python = first(system_which(p) for p in ("python", "python3", "python2"))
+    if not python:
+        click.echo(crayons.red("The Python interpreter can't be found."), err=True)
+        sys.exit(1)
     _cmd = [vistir.compat.Path(python).as_posix()]
     # Run the PEP 508 checker in the virtualenv.
     cmd = _cmd + [vistir.compat.Path(pep508checker_path).as_posix()]


Test patch:
Repository: pypa/pipenv

Issue:
Symlinks are not resolved properly to check location.
https://github.com/pypa/pipenv/blob/237034018a8a2053b0b3b744623ef7f87694fb0e/pipenv/project.py#L50-L54

https://github.com/pypa/pipenv/blob/237034018a8a2053b0b3b744623ef7f87694fb0e/pipenv/environment.py#L508-L519

The path is never resolved if it is an absolute path with symlinked parts. It is often the case with Linux, where the virtualenv home is symlinked to `~/.local/share/`, then `dist_is_in_project` will always return false.

Remove the `is_absolute` check in `_normalize` funciton can make it work.

More info FWIW: I have `virtualenvwrapper` installed and `WORKON_HOME` set to `~/.virtualenvs`


Discussion:

Resolving patch:
diff --git a/pipenv/project.py b/pipenv/project.py
--- a/pipenv/project.py
+++ b/pipenv/project.py
@@ -47,11 +47,10 @@ def _normalized(p):
     if p is None:
         return None
     loc = vistir.compat.Path(p)
-    if not loc.is_absolute():
-        try:
-            loc = loc.resolve()
-        except OSError:
-            loc = loc.absolute()
+    try:
+        loc = loc.resolve()
+    except OSError:
+        loc = loc.absolute()
     # Recase the path properly on Windows. From https://stackoverflow.com/a/35229734/5043728
     if os.name == 'nt':
         matches = glob.glob(re.sub(r'([^:/\\])(?=[/\\]|$)', r'[\1]', str(loc)))


Test patch:
Repository: pypa/pipenv

Issue:
Wildcard version dependency pins wildcard instead of specific version
Spun off from #4263. This is a regression from 2018.11.26.

### Issue description

Dependencies with wildcards get locked with a wildcard version instead of a specific version.

### Steps to replicate

* Run `pipenv install 'example-test-package==1.0.*'`

### Expected result

Pipfile.lock contains:
```
        "example-test-package": {
            "hashes": [
                "sha256:0b164142f6adbef9d719de6885db0ead7b8af66bed3b0a2145dad75420e18a25",
                "sha256:54fec966dab3f3d4f2f5aa6d237bcd30af09a3dc7a0602da0306f39d8c625ec7"
            ],
            "index": "pypi",
            "version": "==1.0.0"
        }
```

### Actual result

Pipfile.lock contains:
```
        "example-test-package": {
            "hashes": [
                "sha256:0b164142f6adbef9d719de6885db0ead7b8af66bed3b0a2145dad75420e18a25",
                "sha256:54fec966dab3f3d4f2f5aa6d237bcd30af09a3dc7a0602da0306f39d8c625ec7"
            ],
            "index": "pypi",
            "version": "==1.0.*"
        }
```


Discussion:
Updated with minimal steps to reproduce.
The problem is in `pipenv.utils.get_locked_dep` here:
https://github.com/pypa/pipenv/blob/b5becd8f3b4b03ca711e662c0f32f681d82d3a54/pipenv/utils.py#L1186-L1197

Looks like this was introduced by 552d1274eacbd04c61f46f639bd967d294f25e6a, which activated the (unused) changes made much earlier in a08a2da52488fa31b1e74b22211f383566fef16b.

Resolving patch:
diff --git a/pipenv/utils.py b/pipenv/utils.py
--- a/pipenv/utils.py
+++ b/pipenv/utils.py
@@ -1191,7 +1191,7 @@ def get_locked_dep(dep, pipfile_section, prefer_pipfile=True):
     lockfile_name, lockfile_dict = lockfile_entry.copy().popitem()
     lockfile_version = lockfile_dict.get("version", "")
     # Keep pins from the lockfile
-    if prefer_pipfile and lockfile_version != version and version.startswith("=="):
+    if prefer_pipfile and lockfile_version != version and version.startswith("==") and "*" not in version:
         lockfile_dict["version"] = version
     lockfile_entry[lockfile_name] = lockfile_dict
     return lockfile_entry


Test patch:
diff --git a/tests/integration/test_lock.py b/tests/integration/test_lock.py
--- a/tests/integration/test_lock.py
+++ b/tests/integration/test_lock.py
@@ -748,3 +748,16 @@ def test_lock_nested_vcs_direct_url(PipenvInstance):
         assert "git" in p.lockfile["default"]["sibling-package"]
         assert "subdirectory" in p.lockfile["default"]["sibling-package"]
         assert "version" not in p.lockfile["default"]["sibling-package"]
+
+
+@pytest.mark.lock
+@pytest.mark.install
+def test_lock_package_with_wildcard_version(PipenvInstance):
+    with PipenvInstance(chdir=True) as p:
+        c = p.pipenv("install 'six==1.11.*'")
+        assert c.ok
+        assert "six" in p.pipfile["packages"]
+        assert p.pipfile["packages"]["six"] == "==1.11.*"
+        assert "six" in p.lockfile["default"]
+        assert "version" in p.lockfile["default"]["six"]
+        assert p.lockfile["default"]["six"]["version"] == "==1.11.0"
Repository: pypa/pipenv

Issue:
CLI requirements dump - broken import and fully qualified function calls
Updates made to `cli.command` have added a call to `exceptions.PipenvOptionsError` -- but `exceptions` is not imported. Additionally, a few `click.echo` calls made it through, but click isn't imported as a fully qualified module.


Discussion:

Resolving patch:
diff --git a/pipenv/cli/command.py b/pipenv/cli/command.py
--- a/pipenv/cli/command.py
+++ b/pipenv/cli/command.py
@@ -9,6 +9,7 @@
 )
 
 from ..__version__ import __version__
+from ..exceptions import PipenvOptionsError
 from ..patched import crayons
 from ..vendor import click_completion, delegator
 from .options import (
@@ -298,6 +299,7 @@ def uninstall(
     if retcode:
         sys.exit(retcode)
 
+
 LOCK_HEADER = """\
 #
 # These requirements were autogenerated by pipenv
@@ -307,11 +309,13 @@ def uninstall(
 #
 """
 
-LOCK_DEV_NOTE="""\
+
+LOCK_DEV_NOTE = """\
 # Note: in pipenv 2020.x, "--dev" changed to emit both default and development
 # requirements. To emit only development requirements, pass "--dev-only".
 """
 
+
 @cli.command(short_help="Generates Pipfile.lock.", context_settings=CONTEXT_SETTINGS)
 @lock_options
 @pass_state
@@ -342,10 +346,10 @@ def lock(
                 header_options.append("--dev-only")
             elif dev:
                 header_options.append("--dev")
-            click.echo(LOCK_HEADER.format(options=" ".join(header_options)))
+            echo(LOCK_HEADER.format(options=" ".join(header_options)))
             # TODO: Emit pip-compile style header
             if dev and not dev_only:
-                click.echo(LOCK_DEV_NOTE)
+                echo(LOCK_DEV_NOTE)
         # Setting "emit_requirements=True" means do_init() just emits the
         # install requirements file to stdout, it doesn't install anything
         do_init(
@@ -356,7 +360,7 @@ def lock(
             pre=state.installstate.pre,
         )
     elif state.lockoptions.dev_only:
-        raise exceptions.PipenvOptionsError(
+        raise PipenvOptionsError(
             "--dev-only",
             "--dev-only is only permitted in combination with --requirements. "
             "Aborting."


Test patch:
Repository: pypa/pipenv

Issue:
Virtualenv name gets botched when PIPENV_PYTHON is a full path and WORKON_HOME is set
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

When trying to `pipenv install` using `PIPENV_PYTHON=$HOME/.pyenv/shims/python` and `WORKON_HOME=$HOME/.pyenv/versions`, the `Project.virtualenv_name` property includes slashes. This causes the virtualenv to get botched since it installs within nested directories.

### Expected result

Generated virtualenv name is something that can be a reasonable folder name.

### Actual result

```
❯ WORKON_HOME=$HOME/.pyenv/versions PIPENV_PYTHON=$HOME/.pyenv/shims/python PYENV_VERSION=3.7.7 pipenv install --dev
Creating a virtualenv for this project…
Pipfile: /Users/Diego/work/lucerna/test/Pipfile
Using /Users/Diego/.pyenv/shims/python (3.7.7) to create virtualenv…
⠦ Creating virtual environment...created virtual environment CPython3.7.7.final.0-64 in 691ms
  creator CPython3Posix(dest=/Users/Diego/.pyenv/versions/test-VgJQqnWV-/Users/Diego/.pyenv/shims/python, clear=False, global=False)
  seeder FromAppData(download=False, pip=latest, setuptools=latest, wheel=latest, via=copy, app_data_dir=/Users/Diego/Library/Application Support/virtualenv/seed-app-data/v1.0.1)
  activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator

✔ Successfully created virtual environment!
Virtualenv location: /Users/Diego/.pyenv/versions/test-VgJQqnWV-/Users/Diego/.pyenv/shims/python
```


Discussion:
yikes, thanks for the report. I'm not sure what to consider this, it's an input sanitization issue I suppose.  I'm not sure how often anyone is trying this.

Was this something you encountered organically? Was the range of possible values confusing?

Resolving patch:
diff --git a/pipenv/project.py b/pipenv/project.py
--- a/pipenv/project.py
+++ b/pipenv/project.py
@@ -443,7 +443,13 @@ def get_name(name, location):
     def virtualenv_name(self):
         # type: () -> str
         sanitized, encoded_hash = self._get_virtualenv_hash(self.name)
-        suffix = "-{0}".format(PIPENV_PYTHON) if PIPENV_PYTHON else ""
+        suffix = ""
+        if PIPENV_PYTHON:
+            if os.path.isabs(PIPENV_PYTHON):
+                suffix = "-{0}".format(os.path.basename(PIPENV_PYTHON))
+            else:
+                suffix = "-{0}".format(PIPENV_PYTHON)
+
         # If the pipfile was located at '/home/user/MY_PROJECT/Pipfile',
         # the name of its virtualenv will be 'my-project-wyUfYPqE'
         return sanitized + "-" + encoded_hash + suffix


Test patch:
Repository: pypa/pipenv

Issue:
Ampersand (&) in folder name breaks pipenv shell
### Issue description

When a new pipenv is created in a folder that contains an ampersand the new environment can't be activated with pipenv shell.

### Expected result

A successfully activated environment.

### Actual result

Error which indicates the path was split on the &.

```
No such file: B-0WFjT3c-/bin/activate
```
### Steps to replicate

```
mkdir A\&B
pipenv shell
```

### Steps to fix

The regular expression in project.Project._sanitize should also include &.

### Workaround

You can create a pipenv in a subfolder of the folder.
Ampersand (&) in folder name breaks pipenv shell
### Issue description

When a new pipenv is created in a folder that contains an ampersand the new environment can't be activated with pipenv shell.

### Expected result

A successfully activated environment.

### Actual result

Error which indicates the path was split on the &.

```
No such file: B-0WFjT3c-/bin/activate
```
### Steps to replicate

```
mkdir A\&B
pipenv shell
```

### Steps to fix

The regular expression in project.Project._sanitize should also include &.

### Workaround

You can create a pipenv in a subfolder of the folder.


Discussion:

Resolving patch:
diff --git a/pipenv/project.py b/pipenv/project.py
--- a/pipenv/project.py
+++ b/pipenv/project.py
@@ -395,7 +395,7 @@ def _sanitize(cls, name):
         #   https://www.gnu.org/software/bash/manual/html_node/Double-Quotes.html
         #   http://www.tldp.org/LDP/abs/html/special-chars.html#FIELDREF
         #   https://github.com/torvalds/linux/blob/2bfe01ef/include/uapi/linux/binfmts.h#L18
-        return re.sub(r'[ $`!*@"\\\r\n\t]', "_", name)[0:42]
+        return re.sub(r'[ &$`!*@"\\\r\n\t]', "_", name)[0:42]
 
     def _get_virtualenv_hash(self, name):
         # type: (str) -> str
diff --git a/pipenv/shells.py b/pipenv/shells.py
--- a/pipenv/shells.py
+++ b/pipenv/shells.py
@@ -1,6 +1,7 @@
 import collections
 import contextlib
 import os
+import re
 import signal
 import subprocess
 import sys
@@ -47,9 +48,9 @@ def _get_activate_script(cmd, venv):
     else:
         suffix = ""
         command = "."
-    # Escape any spaces located within the virtualenv path to allow
+    # Escape any special characters located within the virtualenv path to allow
     # for proper activation.
-    venv_location = str(venv).replace(" ", r"\ ")
+    venv_location = re.sub(r'([ &$])', r"\\\1", str(venv))
     # The leading space can make history cleaner in some shells.
     return " {2} {0}/bin/activate{1}".format(venv_location, suffix, command)
 


Test patch:
Repository: pypa/pipenv

Issue:
Exit With Error Code When pipenv --py Errors Out
### Issue description

When `pipenv --py` is run outside of a virtualenv, it prints the following error message to stderr: "No virtualenv has been created for this project (`/path/to/cwd`) yet!"

### Expected result

I expected `pipenv --py` to give an error (non-zero) exit code in this case.

### Actual result

Pipenv exits with code `0`, indicating success and thereby complicating scripting.

### Steps to replicate

1. `cd / && pipenv -py`


Discussion:
This seems working properly in my environment.

```
bash-3.2$ pipenv --version
pipenv, version 2021.5.29
bash-3.2$ cd / && pipenv --py
No virtualenv has been created for this project (/) yet!
bash-3.2$

```

Which version are you trying and give us the output of the command?

@kobayashi I am using the same version as you. You can use `echo $?` to see that Pipenv incorrectly exits with code `0` indicating success in this case.

Resolving patch:
diff --git a/pipenv/cli/command.py b/pipenv/cli/command.py
--- a/pipenv/cli/command.py
+++ b/pipenv/cli/command.py
@@ -120,7 +120,7 @@ def cli(
             do_where(state.project, bare=True)
             return 0
         elif py:
-            do_py(state.project)
+            do_py(state.project, ctx=ctx)
             return 0
         # --support was passed...
         elif support:
diff --git a/pipenv/core.py b/pipenv/core.py
--- a/pipenv/core.py
+++ b/pipenv/core.py
@@ -1717,7 +1717,7 @@ def ensure_lockfile(project, keep_outdated=False, pypi_mirror=None):
         do_lock(project, keep_outdated=keep_outdated, pypi_mirror=pypi_mirror)
 
 
-def do_py(project, system=False):
+def do_py(project, ctx=None, system=False):
     if not project.virtualenv_exists:
         click.echo(
             "{}({}){}".format(
@@ -1727,7 +1727,7 @@ def do_py(project, system=False):
             ),
             err=True,
         )
-        return
+        ctx.abort()
 
     try:
         click.echo(project._which("python", allow_global=system))


Test patch:
Repository: pypa/pipenv

Issue:
Dead code in core.py
https://github.com/pypa/pipenv/blob/2549656dc09e132d8ba2fa6327c939f5f9a951b7/pipenv/core.py#L1216

Is this line dead code?


Discussion:
Looks like it. Here's the changeset that removes a bunch of similar `sys.exit()` calls, but seems to have missed one. https://github.com/pypa/pipenv/commit/b57240dd45f69859fba3244dc9f642702a700e21

Resolving patch:
diff --git a/pipenv/core.py b/pipenv/core.py
--- a/pipenv/core.py
+++ b/pipenv/core.py
@@ -1203,7 +1203,6 @@ def do_init(
                     )
                 )
                 raise exceptions.DeployException
-                sys.exit(1)
             elif (system or allow_global) and not (project.s.PIPENV_VIRTUALENV):
                 click.echo(
                     crayons.yellow(fix_utf8(


Test patch:
Repository: pypa/pipenv

Issue:
CLI docs broken
### Issue description
[CLI docs](https://pipenv.pypa.io/en/latest/cli/)
[CLI docs source](https://pipenv.pypa.io/en/latest/_sources/cli.rst.txt)

### Expected result
CLI docs

### Actual result
Empty page


Discussion:
It seems the whole https://pipenv.pypa.io/ website is having HTTP 403 errors.

This site is still listed as the documentation home of pipenv at the bottom of the repository README.
The page @Berbe linked to for CLI docs renders the phrase `Pipenv CLI Reference` which is what CLI docs source has in the source.  Otherwise it is just a blank set of documentation checked into the source.  What is the ask here?
@matteius There used to be actual documentation at that location, [WaybackMachine snapshot from May 8, 2021](http://web.archive.org/web/20210508175543/https://pipenv.pypa.io/en/latest/cli/).  Sometime between May 8, 2021 and [Aug 12, 2021](http://web.archive.org/web/20210812022148/https://pipenv.pypa.io/en/latest/cli/) the documentation disappeared.

Was the documentation intentionally removed?

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -24,6 +24,13 @@
 with open(os.path.join(here, "..", "pipenv", "__version__.py")) as f:
     exec(f.read(), about)
 
+# Hackery to get the CLI docs to generate
+import click
+
+import pipenv.vendor.click
+
+click.BaseCommand = pipenv.vendor.click.BaseCommand
+
 # -- General configuration ------------------------------------------------
 
 # If your documentation needs a minimal Sphinx version, state it here.
@@ -38,7 +45,7 @@
     "sphinx.ext.todo",
     "sphinx.ext.coverage",
     "sphinx.ext.viewcode",
-    "sphinx_click.ext",
+    "sphinx_click",
 ]
 
 # Add any paths that contain templates here, relative to this directory.
@@ -124,7 +131,7 @@
 
 
 def setup(app):
-    app.add_stylesheet("custom.css")
+    app.add_css_file("custom.css")
 
 
 # -- Options for HTMLHelp output ------------------------------------------


Test patch:
Repository: pypa/pipenv

Issue:
CLI docs broken
### Issue description
[CLI docs](https://pipenv.pypa.io/en/latest/cli/)
[CLI docs source](https://pipenv.pypa.io/en/latest/_sources/cli.rst.txt)

### Expected result
CLI docs

### Actual result
Empty page


Discussion:
It seems the whole https://pipenv.pypa.io/ website is having HTTP 403 errors.

This site is still listed as the documentation home of pipenv at the bottom of the repository README.
The page @Berbe linked to for CLI docs renders the phrase `Pipenv CLI Reference` which is what CLI docs source has in the source.  Otherwise it is just a blank set of documentation checked into the source.  What is the ask here?
@matteius There used to be actual documentation at that location, [WaybackMachine snapshot from May 8, 2021](http://web.archive.org/web/20210508175543/https://pipenv.pypa.io/en/latest/cli/).  Sometime between May 8, 2021 and [Aug 12, 2021](http://web.archive.org/web/20210812022148/https://pipenv.pypa.io/en/latest/cli/) the documentation disappeared.

Was the documentation intentionally removed?
I looked into this today.  I see what is happening, but not yet why it would have changed behavior after 2021.5.29

The sphinx build error is:  `/home/matteius/pipenv/docs/cli.rst:6: ERROR: "<class 'pipenv.cli.options.PipenvGroup'>" of type "pipenv:cli" is not derived from "click.BaseCommand"`

Verified in shell:
```
>>> from pipenv import cli
>>> import click
>>> isinstance(cli, click.BaseCommand)
False
```

For some reason in 2021.5.29 it is:
```
>>> from pipenv import cli
>>> import click
>>> isinstance(cli, click.BaseCommand)
True
```

Well I figured out what the change is -- we vendored click into the project, and so now in sphinx-click it is not detecting that we sub-class from click, because we are subclassing from pipenv.vendor.click.   Not clear what the easy fix will be, but that is why the docs are blank for CLI currently.
I fixed it using the sphinx conf.py and patched the class of click to be our vendored class.   The docs should generate upon the next release.
@matteius the cli docs page (https://pipenv.pypa.io/en/latest/cli/) is still empty.  There was a release a couple days ago so I assume the docs should have been generated?
Well that's a bummer.  It was definitely fixed in a recent release, that I verified.   Apparently something about that monkeypatch for the docs build is fragile.  Will look into it at some point.

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -31,7 +31,7 @@
 
 click.Command = pipenv.vendor.click.Command
 click.Group = pipenv.vendor.click.Group
-
+click.BaseCommand = pipenv.vendor.click.BaseCommand
 # -- General configuration ------------------------------------------------
 
 # If your documentation needs a minimal Sphinx version, state it here.


Test patch: