Locking is taking a long time. It is me or pipenv?

[jackiekazil]

It seems that I am getting hung up on Locking [dev-packages] dependencies….

I was able to get the pipenv to run just two weeks ago in a few minutes, but now it is taking 30+ before I kill it. Not sure if this is a me issue OR if this is a pipenv issue. I don't know how to diagnose. Either.

Can someone help me navigate?

$ pipenv --support

Pipenv version: '2018.11.26'

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

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

Python installations found:

• 3.7.3: /usr/local/opt/python/libexec/bin/python
• 3.7.3: /usr/local/bin/python3.7m
• 2.7.15: /usr/local/bin/python
• 2.7.15: /usr/local/bin/pythonw
• 2.7.10: /usr/bin/python
• 2.7.10: /usr/bin/pythonw
• 2.7.10: /usr/bin/python2.7

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '3.7.3',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '18.6.0',
 'platform_system': 'Darwin',
 'platform_version': 'Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT '
                     '2019; root:xnu-4903.261.4~2/RELEASE_X86_64',
 'python_full_version': '3.7.3',
 'python_version': '3.7',
 'sys_platform': 'darwin'}

System environment variables:

• GREP_COLOR
• rvm_bin_path
• SPARK_HOME
• VIRTUALENVWRAPPER_SCRIPT
• VIRTUALENVWRAPPER_PROJECT_FILENAME
• TERM_PROGRAM
• GEM_HOME
• NVM_CD_FLAGS
• TERM
• SHELL
• HISTSIZE
• CLICOLOR
• IRBRC
• TMPDIR
• Apple_PubSub_Socket_Render
• TERM_PROGRAM_VERSION
• CODE_HOME
• SPARK_OPTS
• OLDPWD
• MY_RUBY_HOME
• TERM_SESSION_ID
• LOCALBASH
• NVM_DIR
• HISTFILESIZE
• USER
• _system_type
• EC2_HOME
• rvm_path
• PYSPARK_PYTHON
• PYSPARK_DRIVER_PYTHON
• SSH_AUTH_SOCK
• __CF_USER_TEXT_ENCODING
• WORKON_HOME
• PROJECT_HOME
• LSCOLORS
• rvm_prefix
• VIRTUALENVWRAPPER_PYTHON
• PATH
• VIRTUALENVWRAPPER_HOOK_DIR
• INPUTRC
• PWD
• EDITOR
• LANG
• PGHOST
• ITERM_PROFILE
• ENVS_HOME
• GITHUB_TOKEN2
• _system_arch
• XPC_FLAGS
• VIRTUALENVWRAPPER_VIRTUALENV
• PS1
• _system_version
• HISTIGNORE
• HISTCONTROL
• XPC_SERVICE_NAME
• rvm_version
• SHLVL
• HOME
• COLORFGBG
• GREP_OPTIONS
• LC_TERMINAL_VERSION
• ITERM_SESSION_ID
• PYTHONPATH
• LESS
• LOGNAME
• VIRTUALENVWRAPPER_VIRTUALENV_ARGS
• GEM_PATH
• GITHUB_TOKEN
• NVM_BIN
• PYSPARK_DRIVER_PYTHON_OPTS
• VIRTUALENVWRAPPER_WORKON_CD
• LC_TERMINAL
• RUBY_VERSION
• SQLITE_EXEMPT_PATH_FROM_VNODE_GUARDS
• _system_name
• COLORTERM
• _
• PIP_DISABLE_PIP_VERSION_CHECK
• PYTHONDONTWRITEBYTECODE
• PIP_SHIMS_BASE_MODULE
• PIP_PYTHON_PATH
• PYTHONFINDER_IGNORE_UNSUPPORTED

Pipenv–specific environment variables:

Debug–specific environment variables:

• PATH: /Users/jlk/.rvm/gems/ruby-2.2.1/bin:/Users/jlk/.rvm/gems/ruby-2.2.1@global/bin:/Users/jlk/.rvm/rubies/ruby-2.2.1/bin:/Users/jlk/.nvm/versions/node/v5.0.0/bin:/usr/local/opt/python/libexec/bin:/Users/jlk/bin:/usr/local/bin:/usr/local/opt/ruby/bin:/Users/jlk/bin:/usr/local/sbin:/usr/local/mysql/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/usr/local/Cellar/ec2-api-tools/1.6.12.2/libexec/bin:/Users/jlk/.rvm/bin
• SHELL: /bin/bash
• EDITOR: vim
• LANG: en_US.UTF-8
• PWD: /Users/jlk/Projects/code/dag_all/dag

---

Contents of Pipfile ('/Users/jlk/Projects/code/dag_all/dag/Pipfile'):

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

[dev-packages]
flake8 = "*"
pytest = "*"

[packages]
python-dotenv = "*"
jupyter = "*"
pydevex = {editable = true,path = "./../pydevex"}

[requires]
python_version = "3.7"

[connormcmk]

I wrote an SO answer about this, though I would appreciate feedback if I'm wrong.

Essentially, either you are installing a large package and need to wait, or you need to run pipenv lock --clear.

There is already a thread for this which you can find here.

[frostming]

Fairly enough with respect to the link to #2681 ，this one can be closed.

[jackiekazil]

For now, it is fair to close this, because I was able to get it to work. Not sure what I did in the process though. 🤷‍♀

However, for the record when trying to troubleshoot the issue, I found #2681 in the process and read through it. It did not solve the issue and pipenv lock --clear ended up erroring out. However, I can't more details, because now it seems to be working. I still wanted to document that there is something else that is still happening that #2681 doesn't seem to resolve.