New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`pipenv install XYZ` command sometimes hangs indefinitely at "Locking [packages] dependencies" #1816

Closed
MarenstainBear opened this Issue Mar 21, 2018 · 78 comments

Comments

Projects
None yet
@MarenstainBear
Copy link

MarenstainBear commented Mar 21, 2018

Similar to these issues:

Summary

When using pipenv install XYZ, the process hangs indefinitely at "Locking [packages] dependencies".

This doesn't happen every time, and may be related to which package is being installed. This morning it is happening every time I try to install tensorflow. Last night it was happening for numpy as well, but today numpy is fine.

The hanged response seems to last indefinitely (though I did manually terminate the process after an hour). The Pipfile.lock is not written, but the Pipfile is written and the expected packages are installed and listed when I run pipenv run pip freeze.

I was able to reproduce this using various permutations of:

  • (L)ubuntu 16.04 and (X)ubuntu 17.10
  • pipenv --three and pipenv --two
  • pipenv installed through python 2.7 and pipenv installed through python 3.5
  • ...and I downloaded the pipenv source and installed that in an isolated environment to see if the issue was specific to pipenv version 11.8.3. I experienced the same behavior in 11.9.0.

I am also able to reproduce it by simply running pipenv lock or pipenv update if I have tensorflow (or whatever package is currently causing me trouble) listed in my Pipfile.

$ python -m pipenv.help output

Pipenv version: '11.8.3'

Pipenv location: '/home/mary/.local/lib/python2.7/site-packages/pipenv'

Python location: '/usr/bin/python'

Other Python installations in PATH:

  • 2.7: /usr/bin/python2.7

  • 2.7: /usr/bin/python2.7

  • 3.5: /usr/bin/python3.5m

  • 3.5: /usr/bin/python3.5

  • 2.7.12: /usr/bin/python

  • 2.7.12: /usr/bin/python2

  • 3.5.2: /usr/bin/python3

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '0',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.13.0-37-generic',
 'platform_system': 'Linux',
 'platform_version': '#42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018',
 'python_full_version': '2.7.12',
 'python_version': '2.7',
 'sys_platform': 'linux2'}

System environment variables:

  • MANDATORY_PATH
  • _LXSESSION_PID
  • XDG_GREETER_DATA_DIR
  • PROJECT_HOME
  • LC_CTYPE
  • PYTHONDONTWRITEBYTECODE
  • XDG_CURRENT_DESKTOP
  • XDG_SESSION_TYPE
  • LOGNAME
  • XDG_SEAT
  • PATH
  • XDG_VTNR
  • QT_PLATFORM_PLUGIN
  • PYTHONUNBUFFERED
  • VIRTUALENVWRAPPER_SCRIPT
  • ZSH
  • DISPLAY
  • SSH_AGENT_PID
  • LANG
  • TERM
  • SHELL
  • XDG_SESSION_PATH
  • XAUTHORITY
  • LANGUAGE
  • SHLVL
  • QT_LINUX_ACCESSIBILITY_ALWAYS_ON
  • QT_QPA_PLATFORMTHEME
  • SESSION_FOLDER
  • QT_ACCESSIBILITY
  • WINDOWID
  • LIBVIRT_DEFAULT_URI
  • HOME
  • XDG_SESSION_DESKTOP
  • SAL_USE_VCLPLUGIN
  • XDG_RUNTIME_DIR
  • WORKON_HOME
  • SSH_AUTH_SOCK
  • VTE_VERSION
  • GDMSESSION
  • VIRTUALENVWRAPPER_WORKON_CD
  • XDG_SEAT_PATH
  • PIP_PYTHON_PATH
  • XDG_SESSION_ID
  • DBUS_SESSION_BUS_ADDRESS
  • _
  • VIRTUALENVWRAPPER_HOOK_DIR
  • VIRTUALENVWRAPPER_PROJECT_FILENAME
  • DESKTOP_SESSION
  • LSCOLORS
  • XDG_CONFIG_DIRS
  • DEFAULTS_PATH
  • XDG_CONFIG_HOME
  • OLDPWD
  • LS_COLORS
  • GDM_LANG
  • XDG_DATA_DIRS
  • PWD
  • XDG_MENU_PREFIX
  • LESS
  • PAGER
  • USER

Pipenv–specific environment variables:

Debug–specific environment variables:

  • PATH: /home/mary/bin:/home/mary/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
  • SHELL: /usr/bin/zsh
  • LANG: en_US.UTF-8
  • PWD: /home/mary/Development/Projects/poor_mans_smart_camera

Contents of Pipfile ('/home/mary/Development/Projects/poor_mans_smart_camera/Pipfile'):

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

[dev-packages]

[packages]
numpy = "*"
tensorflow = "*"

[requires]
python_version = "3.5"

Expected result

I expect the step in which the Pipfile.lock is generated to take at most a minute.

I have good hardware with lots of free memory and processing power, so I don't think this is a resource constraint. My internet speed is 60 Mbps, so I doubt it is a networking issue when requesting packages.

Actual result

verbose_output.txt

While this screenshot doesn't show verbose output like the file above, it does visually demonstrate what I am experiencing.
image

Steps to replicate
  1. Spin up new virtualenv using pipenv --three or pipenv --two.
  2. Confirm things are working as expected with a package you know is installing fine such as pipenv install pylint.
  3. Now cause it to hang by installing a package that is not working for whatever reason such as pipenv install tensorflow.

Pipfile

@uranusjr

This comment has been minimized.

Copy link
Member

uranusjr commented Mar 21, 2018

Not that this should happen in any case, but what hardware are you running this on?

@MarenstainBear

This comment has been minimized.

Copy link
Author

MarenstainBear commented Mar 21, 2018

@uranusjr Please find the attached hardware information report.
hardinfo_report.txt

@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Mar 22, 2018

Does this happen consistently? Try pipenv lock —verbose —clear

@MarenstainBear

This comment has been minimized.

Copy link
Author

MarenstainBear commented Mar 22, 2018

@techalchemy, I ran pipenv lock --verbose --clear, and the results are similar:

> pipenv lock --verbose --clear
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done

Locking [packages] dependencies…

It remained hung at "Locking [packages] dependencies".

Any luck reproducing this on your machine? With tensorflow in particular, it is happening every time for me.


EDIT: I tested this out on a friend's computer. He's running Ubuntu 17.10, and he did not experience the problem. Both computers are on the same network. One difference between his computer and mine is that he only installed pipenv rather than pipenv and virtualenvwrapper. I'll spin up a virtual machine to see if this is somehow connected to virtualenvwrapper and/or the environment variables I have set that are shared across both (i.e. $WORKON_HOME).

@roddds

This comment has been minimized.

Copy link

roddds commented Mar 22, 2018

I'm currently seeing the same problem; my pipenv lock --verbose --clear output looks exactly like @MarenstainBear's. I'm running Ubuntu and am using pyenv to manage virtualenvs.

hardinfo_report.txt

@uranusjr

This comment has been minimized.

Copy link
Member

uranusjr commented Mar 22, 2018

I see you installed Pipenv against the system Python. Do you happen to have pyopenssl (or something else SSL-related, honestly I can’t remember, it’s part of requests[security]) installed to the same environment? This is known to make the operations extremely slow.

@roddds

This comment has been minimized.

Copy link

roddds commented Mar 22, 2018

I've installed requests[security] and pyopenssl inside the virtualenv just to make sure, but It's still hanging. Debugging further, I've found that it hangs inside venv_resolve_deps the second time around, specifically in line 376, c = delegator.run(cmd, block=True).

What's weirder is that if I run that command directly (python resolver.py), from the command line, it runs perfectly.

@MarenstainBear

This comment has been minimized.

Copy link
Author

MarenstainBear commented Mar 22, 2018

Yes, it appears as though I do, but only for my python 2, not for python 3 (and my pipenv instance was installed through the python 2 version of pip):

mary@marvel:~$ /usr/bin/python2.7 -m pip freeze | grep -i ssl
pyOpenSSL==17.5.0
mary@marvel:~$ /usr/bin/python3 -m pip freeze | grep -i ssl
mary@marvel:~$ 

I'll go pop over to my other laptop and into some virtual environments where I can't reproduce this to see if they do not have pyOpenSSL.

EDIT: Deleted a couple of paragraphs about another issue I was seeing. That was my error--I was actually in a subdirectory but didn't realize it because without my normal zsh configuration disabled for testing purposes, I no longer had a visual indicator in my prompt of my cwd. As @uranusjr correctly stated "but Pipenv does a lot of environment detection, and is known to work weirdly in an improperly-configured shell."... I indeed had momentarily incorrectly configured my shell.


@uranusjr
EDIT 2: I tested this out on a virtual machine with a pretty similar setup to my host machine (including installing pipenv against a python 2.7.12 environment containing the pyOpenSSL module), and on that machine everything is working perfectly as expected. That gives me doubt that pyOpenSSL is the problem here. (I did note that the pipenv version is higher on my virtual machine, so I think I'll upgrade pipenv locally to see if that makes a difference.)

$ python -m pipenv.help output (from the virtual machine)

Pipenv version: '11.9.0'

Pipenv location: '/home/mary/.local/lib/python2.7/site-packages/pipenv'

Python location: '/usr/bin/python'

Other Python installations in PATH:

  • 2.7: /usr/bin/python2.7

  • 2.7: /usr/bin/python2.7

  • 3.5: /usr/bin/python3.5m

  • 3.5: /usr/bin/python3.5

  • 2.7.12: /usr/bin/python

  • 2.7.12: /usr/bin/python2

  • 3.5.2: /usr/bin/python3

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '0',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.13.0-36-generic',
 'platform_system': 'Linux',
 'platform_version': '#40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018',
 'python_full_version': '2.7.12',
 'python_version': '2.7',
 'sys_platform': 'linux2'}

System environment variables:

  • XDG_GREETER_DATA_DIR
  • GNOME_DESKTOP_SESSION_ID
  • PYTHONDONTWRITEBYTECODE
  • LESSOPEN
  • XDG_SESSION_TYPE
  • QT_IM_MODULE
  • LOGNAME
  • USER
  • PROMPT_COMMAND
  • HOME
  • XDG_VTNR
  • PATH
  • PYTHONUNBUFFERED
  • DISPLAY
  • SSH_AGENT_PID
  • LANG
  • TERM
  • SHELL
  • XDG_SESSION_PATH
  • QT_STYLE_OVERRIDE
  • LANGUAGE
  • SESSION_MANAGER
  • SHLVL
  • QT_LINUX_ACCESSIBILITY_ALWAYS_ON
  • GTK_CSD
  • QT_ACCESSIBILITY
  • XMODIFIERS
  • GIO_LAUNCHED_DESKTOP_FILE_PID
  • XDG_SESSION_DESKTOP
  • GIO_LAUNCHED_DESKTOP_FILE
  • XDG_RUNTIME_DIR
  • SSH_AUTH_SOCK
  • VTE_VERSION
  • GDMSESSION
  • XDG_SEAT_PATH
  • LESSCLOSE
  • GSETTINGS_SCHEMA_DIR
  • XDG_CURRENT_DESKTOP
  • XDG_SESSION_ID
  • DBUS_SESSION_BUS_ADDRESS
  • _
  • XAUTHORITY
  • DESKTOP_SESSION
  • XDG_CONFIG_DIRS
  • GTK_MODULES
  • GDM_LANG
  • PANTHEON_TERMINAL_ID
  • XDG_DATA_DIRS
  • PWD
  • PIP_PYTHON_PATH
  • XDG_MENU_PREFIX
  • LS_COLORS
  • XDG_SEAT

Pipenv–specific environment variables:

Debug–specific environment variables:

  • PATH: /home/mary/bin:/home/mary/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
  • SHELL: /bin/bash
  • LANG: en_US.UTF-8
  • PWD: /home/mary

@uranusjr

This comment has been minimized.

Copy link
Member

uranusjr commented Mar 22, 2018

@MarenstainBear Which Python do you install Pipenv in? Or do you install Pipenv in another Python, or inside a virtualenv? (Not your project, but Pipenv itself.)

The behaviour you mentioned below is indeed curious, but Pipenv does a lot of environment detection, and is known to work weirdly in an improperly-configured shell. I wouldn’t read it too deeply; it’s probably choking on something else.

@uranusjr

This comment has been minimized.

Copy link
Member

uranusjr commented Mar 22, 2018

@roddds resolver.py takes the depedencies it wants to resolve as an environment variable. Without setting $PIPENV_PACKAGES before running it it would just resolve an empty list—lightning fast as it should be because there’s nothing to resolve.

Try setting PIPENV_PACKAGES first (the format is similar to requirements.txt) and see what happens.

@jlhood

This comment has been minimized.

Copy link

jlhood commented Mar 22, 2018

+1 I'm seeing the same issue trying to install numpy on MacOS. Verified I don't see this issue installing boto3.

% uname -a
Darwin f45c898a1d21.ant.amazon.com 15.6.0 Darwin Kernel Version 15.6.0: Tue Jan  9 20:12:05 PST 2018; root:xnu-3248.73.5~1/RELEASE_X86_64 x86_64
@roddds

This comment has been minimized.

Copy link

roddds commented Mar 22, 2018

@uranusjr this is what I get when checking PIPENV_PACKAGES with the same value that was set inside venv_resolve_deps:

Resolver output
$ PIPENV_PACKAGES=='django -i https://pypi.python.org/simple\ngraphene -i https://pypi.python.org/simple\ngraphene-django -i https://pypi.python.org/simple\npsycopg2 -i https://pypi.python.org/simple\npsycopg2-binary -i https://pypi.python.org/simple\nipython -i https://pypi.python.org/simple\ndjango-manifold==0.1.6 -i https://pypi.python.org/simple\nscipy -i https://pypi.python.org/simple\npython-dateutil -i https://pypi.python.org/simple\ndjango-extensions -i https://pypi.python.org/simple' python /home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py

Traceback (most recent call last):
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", line 92, in init
req = REQUIREMENT.parseString(requirement_string)
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1617, in parseString
raise exc
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1607, in parseString
loc, tokens = self._parse( instring, 0 )
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1379, in _parseNoCache
loc,tokens = self.parseImpl( instring, preloc, doActions )
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 3376, in parseImpl
loc, exprtokens = e._parse( instring, loc, doActions )
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1379, in _parseNoCache
loc,tokens = self.parseImpl( instring, preloc, doActions )
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 3698, in parseImpl
return self.expr._parse( instring, loc, doActions, callPreParse=False )
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1379, in _parseNoCache
loc,tokens = self.parseImpl( instring, preloc, doActions )
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 3359, in parseImpl
loc, resultlist = self.exprs[0]._parse( instring, loc, doActions, callPreParse=False )
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1383, in _parseNoCache
loc,tokens = self.parseImpl( instring, preloc, doActions )
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 2670, in parseImpl
raise ParseException(instring, loc, self.errmsg, self)
pip9._vendor.pyparsing.ParseException: Expected W:(abcd...) (at char 0), (line:1, col:1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", line 82, in init
req = Requirement(req)
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", line 96, in init
requirement_string[e.loc:e.loc + 8]))
pip9._vendor.packaging.requirements.InvalidRequirement: Invalid requirement, parse error at "'=django'"

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", line 83, in
main()
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", line 71, in main
clear=do_clear,
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", line 63, in resolve
verbose=verbose,
File "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", line 426, in resolve_deps
pre,
File "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", line 294, in actually_resolve_reps
c for c in req.parse_requirements(t, session=pip_requests)
File "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", line 294, in
c for c in req.parse_requirements(t, session=pip_requests)
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_file.py", line 93, in parse_requirements
for req in req_iter:
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_file.py", line 158, in process_line
isolated=isolated, options=req_options, wheel_cache=wheel_cache
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", line 235, in from_line
wheel_cache=wheel_cache, constraint=constraint)
File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", line 91, in init
"Invalid requirement: '%s'\n%s" % (req, add_msg))
pip9.exceptions.InstallationError: Invalid requirement: '=django'
= is not a valid operator. Did you mean == ?

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

[packages]
django = ""
graphene = "
"
graphene-django = ""
"psycopg2" = "
"
"psycopg2-binary" = ""
ipython = "
"
django-manifold = "==0.1.6"
scipy = ""
python-dateutil = "
"
django-extensions = "*"

[dev-packages]

[requires]
python_version = "3.6"

@uranusjr

This comment has been minimized.

Copy link
Member

uranusjr commented Mar 23, 2018

@roddds You have a superfluous = in the environ. It’s

$ PIPENV_PACKAGES='django -i [too long, snipped]

But you had

$ PIPENV_PACKAGES=='django ...

The second = got combined with django after it, resulting the syntax error you saw.

@slhck

This comment has been minimized.

Copy link
Contributor

slhck commented Mar 29, 2018

I thought I was seeing the same problem on a fresh install of a Mac (macOS 10.12, Homebrew Python 3), and found several issues related here.

It's a beefy machine, I have good Internet access – not sure what causes it to take so long, but in the end the lockfile was written after about three minutes.

@Victor-Savu

This comment has been minimized.

Copy link

Victor-Savu commented Mar 30, 2018

Same here. Every time I run pipenv install xxx it takes a very long time (2-3 minutes) right after it prints Locking [packages] dependencies…

@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Mar 30, 2018

Locking simply takes a long time folks. Because of python dependency management we have to download each package and run setup.py to get dependencies as needed. For libraries like tensorflow and numpy you may wind up with an sdist which means you are building from source. That is slow. I’ve seen it take 10 minutes. It goes faster if you heat up the cache.

I’m going to close this issue for now until someone can actually show me that their process is hung or not doing anything. We are considering ways to improve this process

@anowlcalledjosh

This comment has been minimized.

Copy link
Contributor

anowlcalledjosh commented Mar 30, 2018

Would it be feasible to display the package that's currently being locked? I think that would at least help to stop people thinking that Pipenv is hanging.

@slhck

This comment has been minimized.

Copy link
Contributor

slhck commented Mar 30, 2018

We are considering ways to improve this process

I'd suggest printing a message that informs the user that $something is being done, which might “take a few minutes”. Right now it looks like the process hangs, which is I guess what gets people to file bug reports or +1 on these (non-)issues.

@Victor-Savu

This comment has been minimized.

Copy link

Victor-Savu commented Mar 30, 2018

@slhck I would be interested to know why this has to take so long to begin with. What kind of work does pipenv need to do in that period?

@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Mar 30, 2018

@anowlcalledjosh I like this suggestion, and have probably wondered what was being locked myself. Not sure why we never thought to print it.

@Victor-Savu as I mentioned. compiling something like numpy or tensorflow.

@MarenstainBear

This comment has been minimized.

Copy link
Author

MarenstainBear commented Mar 30, 2018

@techalchemy My process, as far as I can tell, is actually hanging. I've let it go for five hours before killing it. Looking at top, I didn't see any indication that anything was actually being processed. By contrast, when I install tensorflow in my virtualenv with pip instead of pipenv, it takes just a few seconds.

As you can see in this capture of my terminal, it took my system 12.25 seconds to spin up a new python3 virtualenv and use pip to install tensorflow using the command /usr/bin/time -v pipenv run pip install tensorflow.

If I instead run the command /usr/bin/time -v pipenv install tensorflow, the process appears to be hanging indefinitely at the "Locking [packages] dependencies..." after the installation is already successful.

You can see from this image that after about 59 seconds of actively doing something, the subprocess related to resolver.py stops actively using system resources and, as far as I can tell, will never complete. When I took this screenshot, the process had been running for 16 minutes.

image

@uranusjr

This comment has been minimized.

Copy link
Member

uranusjr commented Mar 30, 2018

@MarenstainBear Pipenv spawns a subprocess inside the virtualenv to perform locking. Would you be able to verify if the subprocess (the virtualenv python running pipenv/resolver.py is running when Pipenv stuck? I’m wondering if it is stuck inside the resolver, after the resolver returns, or during delegator.run

(even more ideally you can try finding out if the resolver reaches its end)

@MarenstainBear

This comment has been minimized.

Copy link
Author

MarenstainBear commented Mar 30, 2018

@uranusjr I inserted some write statements into the resolver.py code, and looks to be hanging somewhere in the pipenv.utils.resolve_deps call at this line.

In other words, resolver.py does not appear to reach its end.

@uranusjr

This comment has been minimized.

Copy link
Member

uranusjr commented Mar 31, 2018

@MarenstainBear That’s good(?) to hear, at least it means it’s debuggable. How far did it manage to get inside resolve_deps? It’s a pretty long function…

@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Mar 31, 2018

Yeah and for how long was it running? To me that still sounds like what I said before — resolving the dependency graph which is slow

@MarenstainBear

This comment has been minimized.

Copy link
Author

MarenstainBear commented Mar 31, 2018

@techalchemy @uranusjr I'm going to dig into what's going on in the resolve_deps function this weekend. In the meanwhile, here are the results of the process I started yesterday. After 24 hours, it had not resolved, and it really wasn't using any system resources, so I think it was not trying to resolve dependencies and instead just hanging. (I killed the process in order to see the output of the time command.)

Command exited with non-zero status 1
Command being timed: "pipenv install tensorflow"
User time (seconds): 13.63
System time (seconds): 1.99
Percent of CPU this job got: 0%
Elapsed (wall clock) time (h:mm:ss or m:ss): 25:45:02
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 297772
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 467309
Voluntary context switches: 15781
Involuntary context switches: 207
Swaps: 0
File system inputs: 0
File system outputs: 1654976
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 1

@jerryasher

This comment has been minimized.

Copy link

jerryasher commented Apr 1, 2018

@techalchemy what does it mean to "heat up the cache"?

@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Apr 1, 2018

@MarenstainBear thanks for doing all that. Your issue is definitely a bug. Others in the thread I am not yet convinced. Can you install from master and see if we have this fixed?

@MarenstainBear

This comment has been minimized.

Copy link
Author

MarenstainBear commented Apr 2, 2018

@techalchemy I installed from master at commit 8a67a21 (dated Sat Mar 31 01:13:26 2018 -0400). My issue was not resolved. I saw the same behavior here in version 11.9.1 as I was seeing in 11.9.0.

I did briefly try a different way to debug this problem using strace. The command strace pipenv install tensorflow hung at poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, -1). When I looked up those file descriptors, there wasn't much of interest going on other than confirmation that the system is waiting for I/O.

mary@marvel:/proc/8471/fd
> lsof -n -P | grep 1428937     
pipenv     8474                  mary    5r     FIFO               0,12       0t0    1428937 pipe
sh         8543                  mary    1w     FIFO               0,12       0t0    1428937 pipe
python     8544                  mary    1w     FIFO               0,12       0t0    1428937 pipe

mary@marvel:/proc/8471/fd
> lsof -n -P | grep 1428938
pipenv     8474                  mary    7r     FIFO               0,12       0t0    1428938 pipe
sh         8543                  mary    2w     FIFO               0,12       0t0    1428938 pipe
python     8544                  mary    2w     FIFO               0,12       0t0    1428938 pipe
@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Apr 25, 2018

Next release should help with this a bit. Should have it in a few hours.

@ericflores

This comment has been minimized.

Copy link

ericflores commented May 9, 2018

I was experiencing the same problem when installing pandas. As I had faced problems with pandas and the latest version of pip, so I decided to downgrade pip to 9.0.3 and the issue with pipenv also got solved.
Check this issue for your reference: pandas-dev/pandas#20666

@speed-of-light

This comment has been minimized.

Copy link

speed-of-light commented May 22, 2018

pipenv install scrapy
hangs over 10 mins

python --version
3.6.5
pip --version
10.0.1

cat Pipfile

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

[packages]
scrapy = "*"

[dev-packages]

[requires]
python_version = "3.6"
@jakul

This comment has been minimized.

Copy link

jakul commented May 23, 2018

I had the same issue. Here's where it was hanging for me:

$ pipenv lock -vv
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done

Locking [packages] dependencies…
$ pipenv-resolver --debug requests
DEBUG:pip9.vcs:Registered VCS backend: git
DEBUG:pip9.vcs:Registered VCS backend: hg
DEBUG:pip9.vcs:Registered VCS backend: svn
DEBUG:pip9.vcs:Registered VCS backend: bzr
DEBUG:notpip.index:2 location(s) to search for versions of requests:
DEBUG:notpip.index:* https://pypi.python.org/simple/requests/
DEBUG:notpip.index:* https://pypi.boughtbymany.com/5c0a44cd-ec93-412c-b3a9-c3dfb72c22ee/requests/
DEBUG:notpip.index:Getting page https://pypi.python.org/simple/requests/
DEBUG:pip9._vendor.cachecontrol.controller:Looking up "https://pypi.python.org/simple/requests/" in the cache
DEBUG:pip9._vendor.cachecontrol.controller:Returning cached "301 Moved Permanently" response (ignoring date and etag information)
DEBUG:pip9._vendor.cachecontrol.controller:Looking up "https://pypi.org/simple/requests/" in the cache
WARNING:pip9._vendor.cachecontrol.controller:Cache entry deserialization failed, entry ignored
DEBUG:pip9._vendor.urllib3.connectionpool:Starting new HTTPS connection (1): pypi.org
DEBUG:pip9._vendor.urllib3.connectionpool:https://pypi.org:443 "GET /simple/requests/ HTTP/1.1" 200 16346
DEBUG:pip9._vendor.cachecontrol.controller:Updating cache with response from "https://pypi.org/simple/requests/"
DEBUG:pip9._vendor.cachecontrol.controller:Caching due to etag

The problem was something to do with pip trying to write something to it's cache. I was able to resolve it by clearing my pip cache - which for Mac users is rm -rf ~/Library/Caches/pip.

Thanks to all the contributers to this issue!

@woodrad

This comment has been minimized.

Copy link

woodrad commented Jun 18, 2018

Clearing pip’s cache worked for me too! Thanks so much to @MarenstainBear @uranusjr @techalchemy @jtratner for your work!

@renzon

This comment has been minimized.

Copy link

renzon commented Jul 17, 2018

Same stuff here, pip env hanging on Mac OS. I've tried to create a simple pipenv install flask on a new folder only for the sake of testing. It was hanging, but I noted it's was not using pip's cache dir, but its own:

Building wheels for collected packages: itsdangerous, MarkupSafe
  Running setup.py bdist_wheel for itsdangerous: started
  Running setup.py bdist_wheel for itsdangerous: finished with status 'done'
  Stored in directory: /Users/renzo/Library/Caches/pipenv/wheels/2c/4a/61/5599631c1554768c6290b08c02c72d7317910374ca602ff1e5
  Running setup.py bdist_wheel for MarkupSafe: started
  Running setup.py bdist_wheel for MarkupSafe: finished with status 'done'
  Stored in directory: /Users/renzo/Library/Caches/pipenv/wheels/33/56/20/ebe49a5c612fffe1c5a632146b16596f9e64676768661e4e46

So what worked for me was

rm -rf ~/Library/Caches/pipenv

Really strange behaviour. Found this behaviour on after upgrading python from 3.6.3 to 3.7.0

@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Jul 18, 2018

pipenv --clear will handle this for you

@duke79

This comment has been minimized.

Copy link

duke79 commented Jul 21, 2018

Error: no such option: --clear

@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Jul 21, 2018

Upgrade to the latest version first.

edit unless this isn’t released and is only in master. In that case wait until I cut a release probably this week, or use the version available in master :D can’t remember if this actually made the cutoff...

@Mathspy

This comment has been minimized.

Copy link

Mathspy commented Jul 21, 2018

@techalchemy
It's definitely not released yet as I have latest version 2018.7.1 and I don't have --clear option too

@uranusjr

This comment has been minimized.

Copy link
Member

uranusjr commented Jul 21, 2018

For this particular problem, pipenv lock --clear should be enough.

@duke79

This comment has been minimized.

Copy link

duke79 commented Jul 22, 2018

pipenv lock --clear works. Thanks!

Mathspy added a commit to Mathspy/tic-tac-toe-NN that referenced this issue Jul 22, 2018

Locking down packages manually until pipenv matures enough
Sadly due to several issues with Pipfile.lock, it seems to either hang or take forever as seen here pypa/pipenv#2284 here pypa/pipenv#1816 and here pypa/pipenv#356 making it extremely unusuable
For that reason instead of switching to an alternative solution, I have decided to pin all the dependencies so that this project doesn't start failing with breaking changes in the future
I will probably come back here and generate lock and use semver minors/patches only once pipenv have matured enough, good luck to its developers!

Mathspy added a commit to Mathspy/tic-tac-toe-NN that referenced this issue Jul 23, 2018

Locking down packages manually until pipenv matures enough
Sadly due to several issues with Pipfile.lock, it seems to either hang or take forever as seen here pypa/pipenv#2284 here pypa/pipenv#1816 and here pypa/pipenv#356 making it extremely unusuable
For that reason instead of switching to an alternative solution, I have decided to pin all the dependencies so that this project doesn't start failing with breaking changes in the future
I will probably come back here and generate lock and use semver minors/patches only once pipenv have matured enough, good luck to its developers!

Mathspy added a commit to Mathspy/tic-tac-toe-NN that referenced this issue Jul 23, 2018

Locking down packages manually until pipenv matures enough
Sadly due to several issues with Pipfile.lock, it seems to either hang or take forever as seen here pypa/pipenv#2284 here pypa/pipenv#1816 and here pypa/pipenv#356 making it extremely unusuable
For that reason instead of switching to an alternative solution, I have decided to pin all the dependencies so that this project doesn't start failing with breaking changes in the future
I will probably come back here and generate lock and use semver minors/patches only once pipenv have matured enough, good luck to its developers!
@crifan

This comment has been minimized.

Copy link

crifan commented Jul 23, 2018

still NOT work for me for pipenv lock --clear

macOS High Sierra 10.13.6
Python: Python 3.6.4
pipenv: version 2018.7.1

Hope fix this Locking [packages] dependencies... hang forever ASAP

@jakul

This comment has been minimized.

Copy link

jakul commented Jul 23, 2018

@crifan I've found that there's a bug stopping pipenv lock --clear from working (#2628).

Try to manually clear your caches - I use rm -r ~/Library/Caches/pip*.

@braco

This comment has been minimized.

Copy link

braco commented Jul 23, 2018

Happening in this alpine linux based Dockerfile (child of this):

FROM frolvlad/alpine-python3

RUN pip install pipenv

COPY ./app /app
COPY Pipfile /app/
WORKDIR /app

RUN pipenv install

With this Pipfile:

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

[dev-packages]

[packages]
numpy = "*"
pandas = "*"
tensorflow = "*"
flask = "*"

[requires]
python_version = "3.6"
@memeplex

This comment has been minimized.

Copy link

memeplex commented Jul 25, 2018

~/devel/dopper:fixes: pipenv lock --clear --verbose
Locking [dev-packages] dependencies...
Locking [packages] dependencies...

hangs forever.

Pipfile:

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

[packages]
proto = {editable = true, path = "."}
halt = {editable = true, path = "/home/carlos/devel/halt"}
gcd = {editable = true, path = "/home/carlos/devel/gcd"}

[dev-packages]

[requires]
python_version = "3.6"
@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Jul 25, 2018

Lockfiles which only contain stuff that is on your local machine are just as unhelpful as not providing any information. Unless you are offering new debugging information or a new thing that we can take and reproduce, please be mindful about issue tracker noise.

@memeplex

This comment has been minimized.

Copy link

memeplex commented Jul 25, 2018

Those are simple dependency projects that I can easily install manually running pip install -e . on each one, but running pipenv install -e . on the main project hangs indefinitely, so I found out this issue and tried pipenv lock --clear which also hangs. I understand there is not much you can do without further information, but at least this is evidence that things that run smoothly the old way are hanging with pipenv and that the proposed solution is not working everywhere. Sorry I can't provide more information. Maybe if --verbose mode were indeed verbose here.

@memeplex

This comment has been minimized.

Copy link

memeplex commented Jul 25, 2018

Maybe this could shed some light:

~/devel/dopper:fixes: pipenv --rm
Removing virtualenv (/home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s)...
~/devel/dopper:fixes: rm -rf Pipfile 
~/devel/dopper:fixes: pipenv --three
Creating a virtualenv for this project...
Pipfile: /home/carlos/devel/dopper/Pipfile
Using /usr/bin/python3 (3.6.6) to create virtualenv...
⠋Running virtualenv with interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s/bin/python3
Also creating executable in /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s/bin/python
Installing setuptools, pip, wheel...done.
Setting project for dopper-0v9QQl0s to /home/carlos/devel/dopper

Virtualenv location: /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s
Creating a Pipfile for this project...
~/devel/dopper:fixes: pipenv install numpy
Installing numpy...
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/88/29/f4c845648ed23264e986cdc5fbab5f8eace1be5e62144ef69ccc7189461d/numpy-1.15.0-cp36-cp36m-manylinux1_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.15.0

Adding numpy to Pipfile's [packages]...
Pipfile.lock not found, creating...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...

Waiting forever...

Suppose it's a network issue, now why this works then? :

~:: pip install --force --upgrade --user numpy
Collecting numpy
  Downloading https://files.pythonhosted.org/packages/88/29/f4c845648ed23264e986cdc5fbab5f8eace1be5e62144ef69ccc7189461d/numpy-1.15.0-cp36-cp36m-manylinux1_x86_64.whl (13.9MB)
    100% |████████████████████████████████| 13.9MB 386kB/s 
Installing collected packages: numpy
  Found existing installation: numpy 1.15.0
    Uninstalling numpy-1.15.0:
      Successfully uninstalled numpy-1.15.0
Successfully installed numpy-1.15.0
@memeplex

This comment has been minimized.

Copy link

memeplex commented Jul 25, 2018

After a lot of attempts (installing dependencies one by one, avoiding local dependencies, avoiding editable dependencies, installing with skip lock then locking, etc) I was unable to find out any pattern. Sometimes it works in a sensible amount of time, sometimes it aborts after a few minutes with a timeout error, sometimes it hangs "forever" (which definition is contingent on my diminishing patience). I assume my problem is related to the many issues reporting some variant of "locking is too slow".

@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Jul 25, 2018

Again, please stop taking random guesses and posting random snippets of your output. If you want help with a specific problem, fill out an issue with the entire issue template. We are not going on a wild goose chase with anyone in this issue while they selectively post output that is mostly unrelated to pipenv. We have seen what the screen looks like when it hangs. Pasting that to us is not useful.

@memeplex

This comment has been minimized.

Copy link

memeplex commented Jul 25, 2018

@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Jul 26, 2018

@memeplex it's not about it being a random problem, it's about the output not being helpful for troubleshooting. In no place did I call your problem random -- I told you specifically what you can do if you are interested in having a productive conversation about the issue you're facing, since it's impossible to troubleshoot or diagnose a system with selected fragments of terminal output which includes only messages we ourselves wrote and which don't actually include any errors or any way for us to reproduce it.

So far we know:

  1. Nothing about your environment
  2. Nothing about any of the additional circumstances surrounding your system
  3. The exaggerated claim that you 'waited forever' but with no additional info about whether the process was doing anything, whether an environment existed with anything in it, what version of pipenv you are running, whether this happens with things besides numpy, how you installed python, what your hardware is like, what your system configuration is like, I could go on.

We triage a considerable number of issues, which is why we use issue templates to help us gather this information quickly to help assess what might be happening. When people simply paste '[locking]...' and tell us 'this takes forever', we feel for you, but it's kind of an early indication that you aren't actually here to be productive. I try to give the benefit of the doubt and urge people toward filing an issue with the issue template and a reproducible test case, but if you can't do that I can only assume your intention wasn't actually to troubleshoot and that you only wanted to be negative. That is not really welcome on the issue tracker, there are plenty of other places you can do that.

This tracker is used for identifying and solving problems with the codebase, not for piling on anytime you see something that you experienced. The rule is essentially that if you can't or aren't willing to contribute anything beyond restating something and telling us that we need to fix it pronto, you should probably refrain from posting. We are volunteers and we do this in our free time; if you are coming to the tracker you are directly asking for us to spend our time on you. We are usually able to do that, but we ask in return that you follow our process to help us triage efficiently.

@memeplex

This comment was marked as off-topic.

Copy link

memeplex commented Jul 26, 2018

I really don't want to continue this discussion because of the other people subscribed to the thread, I'll answer this one and then you have the last saying if you so desire. I posted some anecdotal evidence, I promptly recognized it wasn't more than that and tried to eliminate the most contingent aspects by installing the local dependencies by other means and checking there were no problems with them and finally by removing every dependence altogether, starting an env from scratch and installing just numpy. Those steps (creating an env and installing numpy) are reproducible, I'm sincerely sorry I can't provide you with more useful information because I myself am unable to find any pattern, as I remarked when listing my attempts (and nor can I attach an iso of my entire setup). Thus, in the end, I suggested a relationship with a number of issues, all too similar, that were reported and closed, by that recognizing that my first impression had been wrong. I understand that reproducible is better but I can't even post a verbose output because the command just shows that minimal output that I (selectively or randomly or whatever) posted. At the beginning I thought my problem could be related to this issue and after my unsuccessful attempts to find some pattern I now feel more inclined to believe it's on the "locking is too slow" side. The reason I didn't create a new issue is that there are many of them closed by the same reason by which you certainly would have closed mine if I were to post it. Now, I think this is an important issue, I'm being unable to consistently install a popular package in a mostly standard setup, it's not about the snake emoji font not working on my new hipster terminal emulator and, while I do understand your position, I can't help feeling that you have been a bit too harsh. That said I really appreciate your detailed explanation after my last, bad tempered, comment. Btw, the claim that I 'waited forever', besides being a figure of speech, was indeed toned down by me, tongue in cheek, by defining forever as the limit of my patience, but I did provide input of it being above several minutes; since we are talking about something that should have taken a few seconds at most here, the only relevance of my imprecision is that you interpreted it as an early symptom of my ill intentions which weren't there to begin with. My apologies to everyone else here, at least to everyone else with the patience to read up to this point.

@pypa pypa locked and limited conversation to collaborators Jul 26, 2018

@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Jul 26, 2018

If you feel you have something new to add on this topic please create a new issue and fill out the issue template in full. We are aware of the problems and their various manifestations, and we have several fixes in process

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.