Latest Pipenv breaks pip-shims inside managed environment

[uranusjr]

Because Pipenv sets PIP_SHIMS_BASE_MODULE to pipenv.patched.notpip, and the pip-shims in the virtual environment cannot find module pipenv.

[uranusjr]

Environment variable is probably the wrong approach for this config.

[techalchemy]

Can you explain what you mean? What is happening that is breaking? Did I cut a release with that env var set?

[techalchemy]

Oh we patch the path to accommodate that pretty much everywhere. Where is it breaking

[uranusjr]

Minimal producible example:

# Pipfile
[packages]
pip-shims = '*'

$ pipenv install --python=3.6
$ pipenv run python -c "import pip_shims"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "venv\lib\site-packages\pip_shims\__init__.py", line 8, in <module>
    from . import shims
  File "venv\lib\site-packages\pip_shims\shims.py", line 334, in <module>
    module = sys.modules[__name__] = _shims()
  File "venv\lib\site-packages\pip_shims\shims.py", line 42, in __init__
    "pip": importlib.import_module(self.BASE_IMPORT_PATH),
  File "lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
ModuleNotFoundError: No module named 'pipenv'

[techalchemy]

See: https://github.com/pypa/pipenv/blob/master/pipenv/resolver.py#L95

[techalchemy]

Can we just unset this in the context of run and shell? Or only set it for the relevant operations I guess?

[uranusjr]

Yeah that would be a reasonable stop gap. I feel pip-shims need to be more robust, however.

[techalchemy]

What do you think is a better approach? I don’t have strong feelings

[uranusjr]

I would expose a top-level function set_pip_module that takes a string (or an imported module) to set the global variable.