Shell for UNKNOWN_VIRTUAL_ENVIRONMENT already activated.

[bakemocho]

Issue description

When deactivating a virtual environment created by pipenv shell and then trying to reactivate it using pipenv shell, I receive the error:

Shell for UNKNOWN_VIRTUAL_ENVIRONMENT already activated.
New shell not activated to avoid nested environments.

However, running unset PIPENV_ACTIVE resolves the issue. Modifying the deactivate function in the virtual environment's activate script to include unset PIPENV_ACTIVE also works.

Expected result

The virtual environment should reactivate without errors when running pipenv shell after deactivating it.

Actual result

The error message is displayed, and the virtual environment is not reactivated.

Steps to replicate

1. Create and activate a virtual environment using pipenv shell.
2. Deactivate the environment using the deactivate command.
3. Attempt to reactivate the environment using pipenv shell.

System details

• OS: Darwin Machinename.local 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:17:33 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6031 arm64
• pyenv version: pyenv 2.4.7
• pipenv version: pipenv, version 2024.0.1
• Python version: Python 3.12.4

Additional information

To resolve the issue temporarily, adding unset PIPENV_ACTIVE to the deactivate function in the virtual environment's activate script works. However, this seems to be an issue with pipenv itself.

pipenv_support.md

[Naofal-Helal]

Pipenv forks the shell and activates the virtualenv in the forked shell, so you can just exit the shell (e.g. by running exit or Ctrl+d) instead of calling deactivate.

If you still want to re-use the forked shell, you can use the --anyway flag for pipenv shell.

If we want to unset PIPENV_ACTIVE, we would need to modify the deactivate function which is generated by virtualenv in the activation scripts for each shell type. But I'm not sure if we should go with this solution.

[bakemocho]

Thank you for your response.

I will start using exit instead of deactivate from now on, but it seems the issue still persists. I appreciate the advice and hope a good solution can be found.

Thanks again for your help.

[matteius]

Issue #6220 Analysis and Proposed Resolution

1. Problem Summary:

The issue highlights a problem with reactivating a Pipenv-created virtual environment after it has been deactivated using the deactivate command. When attempting to reactivate using pipenv shell, users encounter an error stating:

Shell for UNKNOWN_VIRTUAL_ENVIRONMENT already activated.
New shell not activated to avoid nested environments.

This error occurs because the PIPENV_ACTIVE environment variable remains set even after deactivation, leading Pipenv to believe the environment is still active.

2. Comments Analysis:

• Naofal-Helal correctly points out that Pipenv forks the shell and activates the virtual environment within that forked shell. Therefore, using exit to leave the forked shell is the recommended way to deactivate the environment. They also suggest using the --anyway flag with pipenv shell to force reactivation within the same shell. However, the user (bakemocho) confirms that the problem persists even when using exit.
• Naofal-Helal raises a valid concern about modifying the deactivate function generated by virtualenv. This is because it would involve altering code outside Pipenv's control, potentially leading to unforeseen issues.

3. Proposed Resolution:

Given the nature of the problem and the comments, the best approach is to follow Naofal-Helal's suggestion of using the --anyway flag. However, we should improve the user experience by:

• Clarifying the error message: The current error message is confusing, as the environment is not truly "active" in the original shell. A more accurate message would be: Pipenv environment for this project was previously activated in this shell. Use the '--anyway' flag with 'pipenv shell' to reactivate.
• Documenting the recommended workflow: The documentation should clearly state that exit is the preferred way to deactivate a Pipenv environment, and that --anyway should be used for reactivation within the same shell.

4. Code Changes:

a) Modify the error message in pipenv/environments.py:

def is_in_virtualenv():
	  #... (existing code) ...

	  return virtual_env and not (pipenv_active or ignore_virtualenvs)


# In pipenv/cli/command.py
class PipenvGroup(DYMMixin, Group):
	  # ... (existing code) ...

	  def handle_error(self, exc_type, exc_value, traceback):
	      # ... (existing code) ...
	      elif isinstance(exc_value, exceptions.VirtualenvActivationException):
	          # Modify the error message here
	          click.secho(
	              'Pipenv environment for this project was previously activated in this shell.\n'
	              "Use the '--anyway' flag with 'pipenv shell' to reactivate.",
	              fg="yellow",
	              err=True,
	          )

b) Update the documentation in docs/advanced.md:

Add a section that clearly describes the recommended workflow for activating and deactivating Pipenv environments:

## Activating and Deactivating Environments

Pipenv automatically activates the virtual environment when you use `pipenv shell`. 
This creates a forked subshell where the environment is active. To deactivate the environment,
simply exit the subshell by typing `exit` or pressing Ctrl+D.

If you wish to reactivate the environment within the same shell, you can use the `--anyway` flag with `pipenv shell`:

```bash
pipenv shell --anyway

**5. Additional Steps:**

- **Testing:** The proposed changes should be thoroughly tested to ensure they address the issue without introducing regressions.
- **User Feedback:**  Monitor user feedback on the updated documentation and error message to gauge their effectiveness.

This resolution prioritizes user experience by providing clear guidance and a more informative error message, while avoiding potentially disruptive modifications to external code.

[ianmuriuki]

Thank you for the solution, this had really persisted on my project even after trying all the possible solutions.

[chris-zenfolio]

I thought I would throw this out there for anyone seeing this error to be aware of AFTER deleting the virtualenv directory manually.

Example: I had ~/.local/share/virtualenvs/wasabi-5bq1Fq58 on my Mac that was associated with a project directory: ~/dev/tools-python/wasabi

I forgot about pipenv --rm and manually deleted the virtualenv directory and when I returned to the project directory (using OMZsh), pipenv gave the error initially listed in this issue:

Shell for UNKNOWN_VIRTUAL_ENVIRONMENT already activated.
New shell not activated to avoid nested environments.

To resolve, I followed the temporary workaround of unset PIPENV_ACTIVE followed by pipenv shell and everything worked again. See below:

➜  tools-python git:(main) ✗ cd wasabi
No virtualenv has been created for this project/Users/chris/dev/tools-python/wasabi yet!
Aborted!
_togglePipenvShell:source:15: no such file or directory: /bin/activate
➜  wasabi git:(main) ✗ unset PIPENV_ACTIVE
➜  wasabi git:(main) ✗ pipenv shell
Creating a virtualenv for this project
Pipfile: /Users/m/dev/tools-python/wasabi/Pipfile
Using /opt/homebrew/Cellar/[email protected]/3.13.2/Frameworks/Python.framework/Versions/3.13/bin/python33.13.2 to create virtualenv...
⠹ Creating virtual environment...created virtual environment CPython3.13.2.final.0-64 in 2152ms
  creator CPython3macOsBrew(dest=/Users/chris/.local/share/virtualenvs/wasabi-5bq1Fq58, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, via=copy, app_data_dir=/Users/chris/Library/Application Support/virtualenv)
    added seed packages: pip==25.0.1
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

✔ Successfully created virtual environment!
Virtualenv location: /Users/chris/.local/share/virtualenvs/wasabi-5bq1Fq58
Launching subshell in virtual environment...
 source /Users/chris/.local/share/virtualenvs/wasabi-5bq1Fq58/bin/activate

This is more knowledge sharing than anything. It was interesting to see the same directory had been recreated. (The old directory was removed using rm -rf wasabi-5bq1Fq58 from its parent directory.

[ernstki]

Using autoenv with a .env (or some other filename^fn1) results in this error as well.

$ cd my/project
$ export AUTOENV_ENV_FILENAME=.autoenv
$ echo pipenv shell > .autoenv
$ cd .
$ autoenv:
autoenv: WARNING:
autoenv: This is the first time you are about to source /home/me/my/project/.autoenv:
autoenv:
autoenv:   --- (begin contents) ---------------------------------------
autoenv:     pipenv shell$
autoenv:
autoenv:   --- (end contents) -----------------------------------------
autoenv:
autoenv: Are you sure you want to allow this? (y/N) y
Launching subshell in virtual environment...
 source /home/me/.local/share/virtualenvs/my-project-cjQ37tnQ/bin/activate
Shell for UNKNOWN_VIRTUAL_ENVIRONMENT already activated.
New shell not activated to avoid nested environments.

I thought I understood all the mechanisms underlying Python virtualenvs and even autoenv itself, but this came as a suprise to me. Adding --anyway here causes an infinite loop (which is not surprising).

Not suggesting this is a problem for the pipenv maintainers, necessarily. Maybe I'm just holding it wrong? These are two projects (originally) by the same author, so it's probable I'm not the only one using them together in this way.

Edit: I just noticed pipenv has its own .env support, but pipenv and python-dotenv themselves don't seem to do anything with AUTOENV_ENV_FILENAME or .autoenv, so I'm just as puzzled at this result.