Pipenv does not lock dependencies of installed wheels

[martijnarts]

When installing a dependency through a wheel (using either https:// or file://), the initial installation will work fine and install all the library's dependencies into your virtual env. Running pipenv graph will show the dependency tree correctly. The resulting Pipenv.lock file though, will not have the child dependencies of the wheel (even after running pipenv lock again).

I created a repo that shows the error happening in one script: https://github.com/TotempaaltJ/minimal-pipenv-wheel-fail. If you clone it and run test.sh it'll run through the steps, executing them as it goes, to show that it fails to import the dependency after installing straight from a Pipenv.lock file.

$ python -m pipenv.help output

Pipenv version: '11.9.0'

Pipenv location: '/usr/local/lib/python3.6/site-packages/pipenv'

Python location: '/usr/local/opt/python/bin/python3.6'

Other Python installations in PATH:

• 2.7: /usr/bin/python2.7

• 2.7: /usr/bin/python2.7

• 3.6: /usr/local/bin/python3.6m

• 3.6: /usr/local/bin/python3.6

• 2.7.10: /usr/bin/python

• 3.6.4: /usr/local/bin/python3

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '3.6.4',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '17.4.0',
 'platform_system': 'Darwin',
 'platform_version': 'Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST '
                     '2017; root:xnu-4570.41.2~1/RELEASE_X86_64',
 'python_full_version': '3.6.4',
 'python_version': '3.6',
 'sys_platform': 'darwin'}

System environment variables:

• LC_ALL
• LANG
• XPC_FLAGS
• TERM_SESSION_ID
• EDITOR
• GPG_TTY
• COLORTERM
• __CF_USER_TEXT_ENCODING
• ITERM_SESSION_ID
• SSH_AUTH_SOCK
• USER
• PROMPT_DIRTRIM
• PWD
• HOME
• LC_CTYPE
• TERM_PROGRAM
• TERM_PROGRAM_VERSION
• Apple_PubSub_Socket_Render
• ITERM_PROFILE
• TMPDIR
• XPC_SERVICE_NAME
• TERM
• SHELL
• SHLVL
• COLORFGBG
• PROMPT_COMMAND
• LOGNAME
• PATH
• PS1
• OLDPWD
• _
• PYTHONDONTWRITEBYTECODE
• PIP_PYTHON_PATH
• PYTHONUNBUFFERED

Pipenv–specific environment variables:

Debug–specific environment variables:

• PATH: /Users/martijn/.cargo/bin:/Users/martijn/.local/bin:~/workspace/docker/bin:/Users/martijn/bin:/Users/martijn/.local/bin:/home/martijn/.gem/ruby/2.2.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/martijn/.fzf/bin
• SHELL: /usr/local/Cellar/bash/4.4.18/bin/bash
• EDITOR: nvim
• LANG: en_US
• PWD: /Users/martijn/Projects/lib/minimal-pipenv-fail/example

---

Contents of Pipfile ('/Users/martijn/Projects/lib/minimal-pipenv-fail/example/Pipfile'):

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

[packages]
"7abf3e1" = {file = "file:///Users/martijn/Projects/lib/minimal-pipenv-fail/dependency/dist/test_dep-1.0-py3-none-any.whl"}

[dev-packages]

[requires]
python_version = "3.6"

[martijnarts]

I also commented on issue #480, but after figuring out exactly what was happening I wasn't sure if it was the same issue as the creator of that issue had (although it could still be).

[techalchemy]

See #1683 -- not sure if we want to support this but I have a fix anyway

[martijnarts]

not sure if we want to support this

I'm not very familiar with Python's packaging ecosystem, so I'm quite curious how this could be something that shouldn't be supported? Installing wheels from local path/HTTP seems like a straightforward use-case to me. If that's not the case, then I'm probably doing something wrong and I'd love to figure out how to correct that :)

[uranusjr]

@TotempaaltJ The typical usage of installing from local wheels is when you don’t have Internet access, in which case you should have all your dependencies locally anyway (otherwise you’d still need to download them, defeating the purpose). There’s nothing wrong in particular, but a little unconventional.

[martijnarts]

@uranusjr ahh, of course. Thanks! So how about installing wheels over HTTP(S)? We're currently installing one that way thru Github Releases.

[uranusjr]

@TotempaaltJ In that case it’s usually recommended to upload it to an index server—pypi.org if possible, or a private one If making the package public isn’t an option.

[martijnarts]

@uranusjr I'm sure we'll do that eventually, but right now it's a bit overkill for a single library that we need a certain branch of ;) We currently have a workaround (just installing the wheel separately next to pipenv install), so I'll await the PR and see what happens.

Thanks! 🎉

[techalchemy]

@TotempaaltJ installing the wheel is fine, and works fine, and installing its dependencies also works fine, but resolving those dependencies is tricky.

[martijnarts]

@techalchemy Right, sorry! My vocab/semantics was a bit off 😅 We have a make install command that runs pipenv install as well as pipenv install ...whl now.