-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pipenv 2020.6.2 Falsly flags Homebrew's Python as a virtual environment #4316
Comments
Just a note: this was closed as a duplicate (#4341) but I think it adds something to this issue... I'm also experiencing this issue, and to me it seems 2-fold. First, it throws the warning about the existing environment when there is one, but it still will proceed to successfully create a pipenv. However, pipenv --rm will throw the same error and then abort the removal. So pipenv --rm is broken in this case, and the virtualenv must be removed manually |
Seeing this too. Looks like #4341 was closed as a duplicate of this issue? |
To manually remove a pipenv virtualenv: pipenv_venv="$(PIPENV_IGNORE_VIRTUALENVS=1 pipenv --venv)" && rm -rf "${pipenv_venv}" |
@nstapelbroek Just to leave at least one issue open so that newcomers won't file duplicate issues. I didn't notice #4359 , I have closed that one. |
I'm also experiencing this on Red Hat 7 when I install pipenv with pipx and on macOS via brew . From what I can tell though, This also still happens when I install pipenv from the master branch. |
I've had this problem since I entered #%% in the terminal to set up a environment now I can't stop it? |
Came here because of this problem. Are there plans to cut a bugfix release soon? Pipenv is kinda broken for me until that fix is released. |
You can just roll back the version for now.
…On Thu, Jul 16, 2020 at 4:58 PM Christian Hudon ***@***.***> wrote:
Came here because of this problem. Are there plans to cut a bugfix release
soon? Pipenv is kinda broken for me until that fix is released.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4316 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABH47TTTYEIRXN5AXKJQLF3R34IRBANCNFSM4NR726ZQ>
.
|
I just thumbed up the issue a month or so ago, but didn't post a comment here. Yet the problem here just had me determine pipenv to be non-viable to use. I just have a very standard MacOS set up I have (i.e. latest Python 3.8 installed with homebrew). My feedback here is meant with goodwill and respect to the people that put their time in to support the project, and just want to give the feedback that the issue here impacts engagement with the project for another individual here, also. |
So, I'm trying to be as kind as possible. I know how much of the opensource community (to which I am also a part of) is powered by volunteers. But pipenv has been broken for at least a good portion of the macOS Python user base for almost two months now. I know there's are tradeoffs to be made in selecting a threshold for when to do bugfix point release vs when to wait for the next normal release. I would like to very respectfully suggest that this project has its threshold for what requires a bugfix point release set too high currently. In the meantime, I can't use or recommend a core tool that stays broken for this long for a significant portion of its userbase. (If the project changes its mind and wishes to do a bugfix point release, and is lacking the time to port over the patch, I'd be more than happy to help.) |
So what's the way forward with this? |
I ran into this as well. + 1 In the meantime, since I did not want to go through homebrew history (I had pipenv installed via brew), I decided to uninstall the homebrew version (2020.6.2), and installed via my pyenv's pip; i.e. pip install 'pipenv==v2020.5.28'. I ensured that I did not have any Pipfiles in any unwanted directories (e.g. ~) and restarted iTerm2. Seems like things are back to normal - at least until a fix is available. |
Spent hours figuring out what is wrong with my python setup, just to eventually land here. At least change what version brew points to maybe? |
@MiluchOK You would have to take that up with the Homebrew people and I don't think they will downgrade |
This is fixed in Release v2020.8.13. |
Thanks for testing |
Hey Hey 👋,
First off. Thank you for all the work that has gone into the recent releases! I'm happy to use pipenv almost on a daily basis.
Issue description
It seems that the latest pipenv falsely flags my macOS + Python3 via Homebrew as a virtual environment.
The subsequent installation of dependencies does noting on existing projects or fails weirdly with python2 errors on new projects.
Expected result
$ pipenv install
Actual result on new projects
$ pipenv install
Actual result on existing projects
$ pipenv install
Steps to replicate
brew install python
a. Probably unrelated: I've also installed Python 3.8 using homebrew
brew install [email protected]
a. I think my setup is based upon this guide
b. Make sure to reload/reboot any open sessions so the changes in PATH are reflected
pip3 install -U pipenv
to install the latest pipenvpipenv install
in a python projectSystem info
$ pipenv --support
Pipenv version:
'2020.6.2'
Pipenv location:
'/usr/local/lib/python3.7/site-packages/pipenv'
Python location:
'/usr/local/opt/python/bin/python3.7'
Python installations found:
3.7.7
:/usr/local/bin/python3
3.7.7
:/usr/local/bin/python3.7m
3.7.7
:/usr/local/bin/python3.7
3.6.7
:/usr/local/bin/python3.6
3.6.7
:/usr/local/bin/python3.6m
2.7.17
:/usr/local/bin/python2
2.7.17
:/usr/local/bin/python2.7
2.7.16
:/usr/bin/python2.7
PEP 508 Information:
System environment variables:
TERM_SESSION_ID
SSH_AUTH_SOCK
LC_TERMINAL_VERSION
Apple_PubSub_Socket_Render
COLORFGBG
ITERM_PROFILE
XPC_FLAGS
PWD
SHELL
LC_CTYPE
TERM_PROGRAM_VERSION
TERM_PROGRAM
PATH
LC_TERMINAL
COLORTERM
TERM
HOME
TMPDIR
USER
XPC_SERVICE_NAME
LOGNAME
ITERM_SESSION_ID
__CF_USER_TEXT_ENCODING
SHLVL
OLDPWD
ZSH
PAGER
LESS
LSCOLORS
ZNT_REPO_DIR
ZNT_CONFIG_DIR
NVM_DIR
GOPATH
_
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
:/usr/local/opt/openjdk@11/bin:/Users/nico/Library/Android/sdk/platform-tools:/Users/nico/Library/Python/3.7/bin:/Users/nico/Projects/go/bin:/usr/local/bin:/usr/local/sbin:/Users/nico/.poetry/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/usr/local/CrossPack-AVR/bin:/Users/nico/.composer/vendor/bin
SHELL
:/bin/zsh
PWD
:/tmp/cool-project
Contents of
Pipfile
('/private/tmp/cool-project/Pipfile'):Contents of
Pipfile.lock
('/private/tmp/cool-project/Pipfile.lock'):Notes
Assuming that a Homebrew installed python is not supposed to be a virtual environment, I tried digging into this myself and found a possible cause of the bug. Please note that i'm making some assumptions so I'd love to hear your input on this :)
The last release introduced an
_OSX_VENV
variable that is later-on used in the methodis_in_virtualenv()
to determine if the command is running insidea virtual environment. This variable stores the removed value of an
__PYVENV_LAUNCHER__
environment variable, which is originally implemented to prevent faulty shebangs.I suspect that using the
OSX_VENV
variable is too aggressive in determining if we are running inside a virtual environment. I've checked on a different mac setup with a Python 3.7.2 and it seems that the__PYVENV_LAUNCHER__
is also set there.My suggested fix would be to remove the
_OSX_VENV
variable, this works on my machine. Although I'm not sure if this reintroduces #4284Edit: Formatting and typo's
The text was updated successfully, but these errors were encountered: