You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running pipenv install -e . when an extremely large directory is present causes the install process to hang indefinitely.
Removing the large directory allows pipenv to succeed as expected.
Using python setup.py sdist and python setup.py bdist_wheel also complete instantly (and produce a small output), so it seems that the issue is inside of pipenv, rather than when it calls out to build the module.
In my case, a folder containing approximately 1.2 million files across 1.3 million directories.
I added the large directory to MANIFEST.in as a prune element, but it had no effect.
Seems like pipenv is doing a recursive search of the current working directory even though it is not necessary? Or if it is required, perhaps pipenv should respect MANIFEST.in?
Expected result
Pipenv rapidly installs the local package as editable
Actual result
Pipenv hangs indefinitely (consuming a CPU core while doing so)
Steps to replicate
Create a simple python module (in my case, a module with click and a console_scripts entry_point)
Create a massive directory in the workspace. See above for details.
Attempt to install the module using pipenv install -e .
Remove the directory and attempt install again, see that it works promptly
Issue description
Running
pipenv install -e .
when an extremely large directory is present causes the install process to hang indefinitely.Removing the large directory allows pipenv to succeed as expected.
Using
python setup.py sdist
andpython setup.py bdist_wheel
also complete instantly (and produce a small output), so it seems that the issue is inside of pipenv, rather than when it calls out to build the module.In my case, a folder containing approximately 1.2 million files across 1.3 million directories.
I added the large directory to
MANIFEST.in
as aprune
element, but it had no effect.Seems like pipenv is doing a recursive search of the current working directory even though it is not necessary? Or if it is required, perhaps pipenv should respect
MANIFEST.in
?Expected result
Pipenv rapidly installs the local package as editable
Actual result
Pipenv hangs indefinitely (consuming a CPU core while doing so)
Steps to replicate
click
and a console_scripts entry_point)pipenv install -e .
$ pipenv --support
Pipenv version:
'2023.6.2'
Pipenv location:
'/opt/homebrew/Cellar/pipenv/2023.6.2/libexec/lib/python3.11/site-packages/pipenv'
Python location:
'/opt/homebrew/Cellar/pipenv/2023.6.2/libexec/bin/python3.11'
OS Name:
'posix'
User pip version:
'23.0.1'
user Python installations found:
PEP 508 Information:
System environment variables:
PATH
MANPATH
TERM_PROGRAM
SHELL
TERM
HOMEBREW_REPOSITORY
TMPDIR
TERM_PROGRAM_VERSION
TERM_SESSION_ID
USER
SSH_AUTH_SOCK
AWS_DEFAULT_SSO_REGION
_
__CFBundleIdentifier
PWD
LANG
XPC_FLAGS
XPC_SERVICE_NAME
SHLVL
HOME
HOMEBREW_PREFIX
LOGNAME
INFOPATH
HOMEBREW_CELLAR
AWS_DEFAULT_SSO_START_URL
__CF_USER_TEXT_ENCODING
PIP_DISABLE_PIP_VERSION_CHECK
PIP_PYTHON_PATH
PYTHONDONTWRITEBYTECODE
PYTHONFINDER_IGNORE_UNSUPPORTED
Pipenv–specific environment variables:
Debug–specific environment variables:
PATH
:/opt/homebrew/Cellar/pipenv/2023.6.2/libexec/tools:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Users/corry/Library/Application Support/JetBrains/Toolbox/scripts
SHELL
:/bin/zsh
LANG
:en_US.UTF-8
PWD
:/Users/corry/workspace/wren
Contents of
Pipfile
('/Users/corry/workspace/wren/Pipfile'):Contents of
Pipfile.lock
('/Users/corry/workspace/wren/Pipfile.lock'):The text was updated successfully, but these errors were encountered: