Pipenv: `pipenv install XYZ` command sometimes hangs indefinitely at "Locking [packages] dependencies"

Created on 21 Mar 2018 · 78Comments · Source: pypa/pipenv

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.

Steps to replicate

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

Pipfile

Source

MarenstainBear

👍30

Most helpful comment

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.

sersorrel on 30 Mar 2018

👍24

All 78 comments

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

uranusjr on 21 Mar 2018

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

MarenstainBear on 21 Mar 2018

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

techalchemy on 22 Mar 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).

MarenstainBear on 22 Mar 2018

👍3

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

roddds on 22 Mar 2018

👍7

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.

uranusjr on 22 Mar 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.

roddds on 22 Mar 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

MarenstainBear on 22 Mar 2018

👍1

@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 on 22 Mar 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.

uranusjr on 22 Mar 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

jlhood on 22 Mar 2018

👍1

@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"

roddds on 22 Mar 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.

uranusjr on 23 Mar 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.

slhck on 29 Mar 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…

Victor-Savu on 30 Mar 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

techalchemy on 30 Mar 2018

👍3

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.

sersorrel on 30 Mar 2018

👍24

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.

slhck on 30 Mar 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?

Victor-Savu on 30 Mar 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.

techalchemy on 30 Mar 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.

MarenstainBear on 30 Mar 2018

👍4

@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)

uranusjr on 30 Mar 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.

MarenstainBear on 30 Mar 2018

👍3

@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…

uranusjr on 31 Mar 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

techalchemy on 31 Mar 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

MarenstainBear on 31 Mar 2018

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

jerryasher on 1 Apr 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?

techalchemy on 1 Apr 2018

@techalchemy I installed from master at commit 8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d (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

MarenstainBear on 2 Apr 2018

Side note - It would really help if we could somehow stream output from the
resolver rather than blocking until the resolver returns (just to make it
easier to use verbose to debug where hang is happening)
On Sun, Apr 1, 2018 at 5:21 PM MarenstainBear notifications@github.com
wrote:

I installed from master at commit 8a67a21
https://github.com/pypa/pipenv/commit/8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d
(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

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/pypa/pipenv/issues/1816#issuecomment-377828171, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABhjq95pb8cZ7BbzrjPxBq3SLeirzFehks5tkW8KgaJpZM4S0kt-
.

jtratner on 2 Apr 2018

👍1

I'm having the same problem. It hanged indefinitely in the past, but last time it ended with an exception for some reason. Maybe this will help. (Version is 11.9.0)

❯ pipenv install Pipfile.lock not found, creating… Locking [dev-packages] dependencies… Locking [packages] dependencies… y", line 63, in resolve verbose=verbose, File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 494, in resolve_deps list(resolver.resolve_hashes([result]).items())[0][1] File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 72, in resolve_hashes return {ireq: self.repository.get_hashes(ireq) for ireq in ireqs} File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 72, in <dictcomp> return {ireq: self.repository.get_hashes(ireq) for ireq in ireqs} File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 276, in get_hashes for candidate in matching_candidates File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 276, in <setcomp> for candidate in matching_candidates File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 282, in _get_file_hash for chunk in iter(lambda: fp.read(8096), b""): File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 282, in <lambda> for chunk in iter(lambda: fp.read(8096), b""): File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/requests/packages/urllib3/response.py", line 324, in read flush_decoder = True File "/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/contextlib.py", line 99, in __exit__ self.gen.throw(type, value, traceback) File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/requests/packages/urllib3/response.py", line 237, in _error_catcher raise ReadTimeoutError(self._pool, None, 'Read timed out.') pip9._vendor.requests.packages.urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='pypi.python.org', port=443): Read timed out.

roveo on 2 Apr 2018

@MarenstainBear Thanks that you're putting so much effort in debugging this issue.

After the installation of the current version of the tensorflow-gpu package failed many times in the same way described, I've managed to complete its installation by pinning it to version 1.5

pipenv install tensorflow-gpu==1.5

Even though it doesn't explain the NumPy and the other packages installation failures, it might have something to do with the fact that since version 1.6, the tensorflow binaries are using AVX instructions. In any case, version 1.5 installs very fast and works just fine.

paraschas on 2 Apr 2018

@paraschas I tried your tip, and unfortunately it didn't work. Thanks for suggesting something, though! :-)

MarenstainBear on 2 Apr 2018

@MarenstainBear this could easily be due to pipenv leaking file descriptors somewhere along the chain and then waiting for them... During installation we usually fork a bunch of subprocesses to handle concurrent downloads and such. What happens if you use pipenv install --sequential? Thanks for bearing with us, do feel free to stop by our slack channel (link is https://pyslackers.com/ => sign up and join #pipenv) if you want to kick more stuff around in real time

techalchemy on 2 Apr 2018

@techalchemy From what I can tell, when it hangs it is never exiting this try block:
@techttps://github.com/pypa/pipenv/blob/8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d/pipenv/utils.py#L491-L494

That code is calling back into resolver.py, so I'll see what's happening over there in the resolve_hashes() method.

PS - I did join the slack channel. Thanks for the invite!

MarenstainBear on 3 Apr 2018

I'm facing the same issue here. Python 3.6.4, pipenv 11.9.0.
It doesn't hang if I install with --skip-lock.

claytonaalves on 4 Apr 2018

👍5 🎉1

@techalchemy @uranusjr

I was able to use ipdb to narrow my issue down considerably...

From the original pypi.py code here, if I add two lines, as shown below, then my pipenv is no longer broken.

The first line alt_session = PipSession() creates a vanilla PipSession object
And the second line self.session.adapters["https://"] = alt_session.adapters["https://"] grabs the https adapter from that vanilla session and overwrites the PyPIRepository's https adapter. This means it goes from using a pip9._vendor.cachecontrol.adapter.CacheControlAdapter to instead using a pip9._vendor.requests.adapters.HTTPAdapter.

def _get_file_hash(self, location):
    h = hashlib.new(FAVORITE_HASH)
    alt_session = PipSession()
    self.session.adapters["https://"] = alt_session.adapters["https://"]
    with open_local_or_remote_file(location, self.session) as fp:
        for chunk in iter(lambda: fp.read(8096), b""):
            h.update(chunk)
    return ":".join([FAVORITE_HASH, h.hexdigest()])

Any ideas on why this is working for me and what this means about the source of my bug?

MarenstainBear on 11 Apr 2018

My guess is it was probably broken because it was trying to fetch too many things at the same time. Switching to a cached adapter reduces the requests it needs (because they are cached) and made it work. This is almost completely a guess (I didn’t look into pip internals and am speaking purely based on my memory to the pip source). If this is correct, however, this would be a very nice fix. Would you care to tiny up the patch into a pull request?

uranusjr on 11 Apr 2018

@uranusjr It's actually the other way around. The original code is using the cached adapter--the cached adapter is the one that is NOT working for me. The regular HTTP adapter does work when I use it instead.

MarenstainBear on 11 Apr 2018

@uranusjr @techalchemy Now that I think about it, I wonder if there is some kind of corrupt data in my cache. I'll look into how to clear my (pip?) cache to see if that resolves the issue for me.

MarenstainBear on 11 Apr 2018

Probably, I don’t know (pip internal is very difficult). pip’s cache is at ~/.cache/pip by default, but maybe there are other caches. I honestly don’t know.

uranusjr on 11 Apr 2018

@uranusjr @techalchemy @jtratner

Holy buckets, Batman! It worked!

mary@marvel:~
> sudo rm ~/.cache/pip* -rf
[sudo] password for mary: 

mary@marvel:~
> mktmpenv 
Using base prefix '/usr'
New python executable in /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/python3
Also creating executable in /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/python
Installing setuptools, pip, wheel...done.
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/predeactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/postdeactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/preactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/postactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/get_env_details
This is a temporary environment. It will be deleted when you run 'deactivate'.
(tmp-60224356c1829db) 
mary@marvel:~/Development/.virtualenvs/tmp-60224356c1829db
> pipenv install protobuf
Creating a Pipfile for this project…
Installing protobuf…
Collecting protobuf
  Downloading protobuf-3.5.2.post1-cp35-cp35m-manylinux1_x86_64.whl (6.4MB)
Requirement already satisfied: setuptools in ./lib/python3.5/site-packages (from protobuf)
Collecting six>=1.9 (from protobuf)
  Downloading six-1.11.0-py2.py3-none-any.whl
Installing collected packages: six, protobuf
Successfully installed protobuf-3.5.2.post1 six-1.11.0

Adding protobuf to Pipfile's [packages]…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (735738)!
Installing dependencies from Pipfile.lock (735738)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 2/2 — 00:00:00
(tmp-60224356c1829db) 
mary@marvel:~/Development/.virtualenvs/tmp-60224356c1829db
>

Let's see if this solution works for some of the other people reporting the same issue.
@roddds @jlhood @roveo @claytonaalves If you're still able to reproduce pipenv hanging indefinitely at "Lock... [packages] dependencies", try clearing your pip (and pipenv?) cache at ~/.cache/.pip and report back on whether that resolved the issue with pipenv hanging. :-)

MarenstainBear on 11 Apr 2018

👍4 ❤3 🎉3

So your prompt says @marvel but you’re quoting Robin…hmm 😏

uranusjr on 11 Apr 2018

👍3 😄1

lol... so clearing your pip cache fixed it... life is amusing...

techalchemy on 12 Apr 2018

👍1

I run across the same issue with the latest Python, pip, and pipenv while installing pendulum and, unfortunately, clearing pip's and pipenv's cache by running `sudo rm ~/.cache/pip* -rf' doesn't solve the problem.

So the issue, at least for me, still persists.

paraschas on 24 Apr 2018

😕1

@paraschas can you give us the pipfile and the output of python -m pipenv.help

techalchemy on 25 Apr 2018

The contents of the Pipfile are:

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

[packages]
pandas = "*"
"h5py" = "*"
Keras = "*"
tensorflow-gpu = "==1.5"
sklearn = "*"
pendulum = "*"

[dev-packages]

[requires] = "3.6"

And the output of python -m pipenv.help is attached:

pipenv.help.txt

Any ideas on how to bypass the issue, even manually, will be greatly appreciated.

paraschas on 25 Apr 2018

Can you run pipenv-resolver —debug pendulum

techalchemy on 25 Apr 2018

Here it is, not sure of why it fails:

pipenv-resolver_pendulum.txt

paraschas on 25 Apr 2018

When debugging it’s helpful if you don’t cut out the command you executed also because I too have no idea why this is failing. Is your locale configured properly etc?

techalchemy on 25 Apr 2018

I copied the command that I now see includes a dash instead of two hyphens.

I've now run pipenv-resolver --debug pendulum which runs correctly and produces the following results:
pipenv-resolver_pendulum.txt

paraschas on 25 Apr 2018

Sorry about that I triage a lot of stuff on mobile and it auto converts to em-dashes. So this suggests an installation issue. What version winds up in your lockfile? Can you pip install that version of pendulum directly?

techalchemy on 25 Apr 2018

No worries, I see that you're putting a lot of effort to this project.

I managed to install pendulum with pipenv but skipping the generation of the lock file. After a day and with a fresh boot it correctly generated the lock file as well, and the pendulum version is "==1.5.1"

Bad thing is that so far there is no way to reproduce this issue, which makes it difficult to fix, but hopefully something will come up.

paraschas on 25 Apr 2018

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

techalchemy on 26 Apr 2018

🎉3 👍1

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: https://github.com/pandas-dev/pandas/issues/20666

ericflores on 9 May 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"

speed-of-light on 22 May 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!

jakul on 23 May 2018

🎉2

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

woodrad on 18 Jun 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

renzon on 17 Jul 2018

😕1

pipenv --clear will handle this for you

techalchemy on 18 Jul 2018

Error: no such option: --clear

duke79 on 21 Jul 2018

👍1

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...

techalchemy on 21 Jul 2018

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

Mathspy on 21 Jul 2018

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

uranusjr on 21 Jul 2018

👎1 👍1

pipenv lock --clear works. Thanks!

duke79 on 22 Jul 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

crifan on 23 Jul 2018

@crifan I've found that there's a bug stopping pipenv lock --clear from working (https://github.com/pypa/pipenv/issues/2628).

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

jakul on 23 Jul 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"

braco on 23 Jul 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"

memeplex on 25 Jul 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.

techalchemy on 25 Jul 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 on 25 Jul 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 on 25 Jul 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".

memeplex on 25 Jul 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.

techalchemy on 25 Jul 2018

Ok, if you think failing to install numpy in a clean environment is a
random problem I know I'm taking my chances when using pipenv, thanks for
the heads up and I'll shut my mouth up.

On Wed, Jul 25, 2018 at 6:27 PM, Dan Ryan notifications@github.com wrote:

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.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/pypa/pipenv/issues/1816#issuecomment-407901419, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACtq-WfYHCgtRnbIu_yljQV7m0JvwxA7ks5uKOKqgaJpZM4S0kt-
.

memeplex on 26 Jul 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:

Nothing about your environment
Nothing about any of the additional circumstances surrounding your system
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.

techalchemy on 26 Jul 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.

memeplex on 26 Jul 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

techalchemy on 26 Jul 2018

Was this page helpful?

0 / 5 - 0 ratings