pipenv: `pipenv install` throws `--system is intended to be used for pre-existing Pipfile installation`
Issue description
Running pipenv install
in a new project throws an error, if there was a project created before with the same directory path.
Expected result
pipenv should be able to handle this situation without error. Not sure what the best approach would be here.
Steps to replicate
- Create a pipenv project:
$ mkdir foo
$ cd foo
$ pipenv install
- Delete the pipenv project:
$ cd ..
$ rm -rf foo
- Create a new project again:
$ mkdir foo
$ pipenv install
- You get an error:
Usage: pipenv install [OPTIONS] [PACKAGES]...
ERROR:: --system is intended to be used for pre-existing Pipfile installation, not installation of specific packages. Aborting.
$ pipenv --support
Pipenv version: '2022.4.8'
Pipenv location: '/opt/homebrew/Cellar/pipenv/2022.4.8/libexec/lib/python3.10/site-packages/pipenv'
Python location: '/opt/homebrew/Cellar/pipenv/2022.4.8/libexec/bin/python3.10'
Python installations found:
3.9.12
:/opt/homebrew/bin/python3
3.9.12
:/opt/homebrew/bin/python3.9
3.8.9
:/usr/bin/python3
PEP 508 Information:
{'implementation_name': 'cpython',
'implementation_version': '3.10.2',
'os_name': 'posix',
'platform_machine': 'arm64',
'platform_python_implementation': 'CPython',
'platform_release': '21.4.0',
'platform_system': 'Darwin',
'platform_version': 'Darwin Kernel Version 21.4.0: Fri Mar 18 00:47:26 PDT '
'2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T8101',
'python_full_version': '3.10.2',
'python_version': '3.10',
'sys_platform': 'darwin'}
System environment variables:
PATH
MANPATH
NIX_PROFILES
TERM_PROGRAM
_P9K_TTY
SHELL
TERM
HOMEBREW_REPOSITORY
TMPDIR
PYPI_SERVER_PASSWORD
TERM_PROGRAM_VERSION
PIPENV_SYSTEM
TERM_SESSION_ID
USER
SSH_AUTH_SOCK
_
__CFBundleIdentifier
PWD
JAVA_HOME
P9K_SSH
BASE16_THEME
P9K_TTY
XPC_FLAGS
NIX_SSL_CERT_FILE
XPC_SERVICE_NAME
PYPI_SERVER_USER
SHLVL
HOME
HOMEBREW_PREFIX
LOGNAME
LC_CTYPE
INFOPATH
HOMEBREW_CELLAR
__CF_USER_TEXT_ENCODING
PIP_SHIMS_BASE_MODULE
PIP_DISABLE_PIP_VERSION_CHECK
PIP_PYTHON_PATH
PYTHONDONTWRITEBYTECODE
PYTHONFINDER_IGNORE_UNSUPPORTED
Pipenv–specific environment variables:
PIPENV_SYSTEM
:0
Debug–specific environment variables:
PATH
:/opt/homebrew/Cellar/pipenv/2022.4.8/libexec/tools:/Users/ajeet.dsouza/.deno/bin:/Users/ajeet.dsouza/.local/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/Users/ajeet.dsouza/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/ajeet.dsouza/.cargo/bin:/Users/ajeet.dsouza/.local/bin
SHELL
:/bin/zsh
PWD
:/Users/ajeet.dsouza/ws/bot-detection
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 35
- Comments: 39 (3 by maintainers)
There exists another folder having same name of the deleted folder in the beginning, under ‘.virtualenvs’ folder.
This command will find the path of that folder. Then deleting that folder fixed the issue.
I solve this by removing the previous virtualenv.
I’ve solved this issue by removing previous virtualenv like following:
My environment
This is our issue
This is my solution : Remove existing virtualenv
It’s the almost same as MacOS.
Hope this helps you!!
try this
pipenv --rm
Improved solution:
pipenv --rm
Would be nice if code caught this error and suggested that command as an option.
This worked for me. Thanks
I encounter this same issue inside a docker build process. The suggested fix does not apply because there is no pre-existing venv in my case. The image builder starts from scratch obviously.
The pipenv version used is version 2022.4.30. Executing
pipenv --venv
right beforepipenv install --system
confirms that no venv exists yet:Installing
pipenv==2022.1.8
doesn’t help either.EDIT: I looked into pipenv’s code to find out why it does not work. I found that the code checks for Pipfile.lock file existence. Indeed, when I add the Pipfile.lock into the build process, it works. Not sure if this behavior is intentional. I think in this case the error message should be improved, because it does not mention the missing Pipfile.lock at all.
@matteius I fully agree.
In one of my projects I used this workaround in the Dockerfile:
Ugly but it does the job.
I also get this issue. I avoid this by editing
Pipfile
directly.That is equivalent to
pipenv --rm
.This helped me too!
This can be done in one line.
rm -rf "$(pipenv --venv)"
on UNIX systems.Solved
ERROR::
--system is intended to be used for pre-existing Pipfile installation, not installation of specific packages. Aborting.If you are using macOS, I deleted the project file in my virtualenv folder
Hope this helps
Can we have this issue locked so people stop chiming in to offer the same workaround every few weeks, notifying 32+ people each time?
Run
pipenv --rm
thenpipenv install
Worked for meYeah, I could use some help with some of these long standing issues to be honest. For context, the weather here is amazing and gardening season is happening, so my time will be limited to mostly reviewing other’s efforts and making suggestions and new releases until the Fall/Winter cycle again. With regards to this system issue, I don’t even understand the concept that
--system is intended to be used for pre-existing Pipfile installation, not installation of specific packages. Aborting.
– My question is why the heck canpipenv
not be used to install system level packages when pip does this by default?I don’t think that removing a local virtualenv is the desired solution, it is more of a workaround. I think the --system flag should be able to install things at a system level when it is supplied, and presumably there is a Pipfile config option for specifying to always install to the system level. This would better support the ability to do what people want to do, and for whatever the reason – maybe it is they are running a Docker container that just uses the root user, though I tend to agree its better to have an actual user – either way, some folks may not want the overhead of using virtualenv in their docker containers for whatever reason. Am I making any sense? Going back outside before it gets too hot.
I can replicate as well. Removing existing environment works.