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

  1. Create a pipenv project:
$ mkdir foo
$ cd foo
$ pipenv install
  1. Delete the pipenv project:
$ cd ..
$ rm -rf foo
  1. Create a new project again:
$ mkdir foo
$ pipenv install
  1. 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)

Most upvoted comments

There exists another folder having same name of the deleted folder in the beginning, under ‘.virtualenvs’ folder.

pipenv --venv

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

CentOS Linux release 7.9.2009 (Core)
pipenv Version: 2022.4.8
pip Version: 21.3.1

This is our issue

cd dir_python
pipenv --python 3
> Usage: pipenv [OPTIONS] COMMAND [ARGS]...
> ERROR:: --system is intended to be used for pre-existing Pipfile installation, not installation of specific packages. Aborting.

This is my solution : Remove existing virtualenv

# Check where virtual venv is
pipenv --venv
> /home/0816keisuke/.local/share/virtualenvs/dir_python-5Rka8dPB

# Remove existing virtualenv
cd ~/.local/share/virtualenvs
rm -rf dir_python-5Rka8dPB

# Remake virtualenv
cd ~/dir_python
pipenv --python 3

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.

There exists another folder having same name of the deleted folder in the beginning, under ‘.virtualenvs’ folder.

pipenv --venv

This command will find the path of that folder. Then deleting that folder fixed the issue.

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 before pipenv install --system confirms that no venv exists yet:

No virtualenv has been created for this project(/app) 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:

# Copy only the Pipfile.
COPY Pipfile ./

# Generate the Pipfile.lock during the image build process, then immediately remove the venv.
RUN pipenv lock && pipenv --clear && pipenv --rm

# Now install from Pipfile.lock into system packages...
RUN pipenv install --system --deploy

Ugly but it does the job.

I also get this issue. I avoid this by editing Pipfile directly.

That is equivalent to pipenv --rm.

There exists another folder having same name of the deleted folder in the beginning, under ‘.virtualenvs’ folder.

pipenv --venv

This command will find the path of that folder. Then deleting that folder fixed the issue.

This helped me too!

There exists another folder having same name of the deleted folder in the beginning, under ‘.virtualenvs’ folder.

pipenv --venv

This command will find the path of that folder. Then deleting that folder fixed the issue.

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

  1. Using GO I went to this folder -> “.local/share/virtualenvs/”
  2. Take note of your project folder name, if your project folder is “myProject”, in the virtualenv folder, you will see your project name with alphanumeric appended at its end, I simply moved to Bin
  3. created a new project with “pipenv install” and the error was gone

Virtualenv location: /Users/your-computer-name/.local/share/virtualenvs/myProject-0dhhge

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 then pipenv install Worked for me

Yeah, 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 can pipenv 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.