Recreating virtualenv when python_version changes instead of warning
See original GitHub issueWhen the “python_version” in a Pipfile changes I get warnings but i manually have to run pipenv install --python X.X
.
My understanding of the idea of pipenv is, that running pipenv update
will sync my virtualenv with my Pipfile (without need for manual interaction). Thus: why is this not the case for changing the python version.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:6 (4 by maintainers)
Top Results From Across the Web
Wrong Python version when using Virtualenv in ...
It looks to me like your virtualenv has somehow got both version 2.7 and version 3.3 of Python in it. Try deleting it...
Read more >venv — Creation of virtual environments — Python 3.11.1 ...
The venv module supports creating lightweight “virtual environments”, each with their own independent set of Python packages installed in their site ...
Read more >How to manage multiple Python versions and virtual ...
If you are using a single version of Python say version 3.3+, and want to manage different virtual environments, then venv is all...
Read more >Rebuilding a Virtualenv - PythonAnywhere help
If you need to rebuild your virtualenv following a system image upgrade ... Using the appropriate Python version in place of X.Y :...
Read more >Python Virtual Environments: A Primer
In this tutorial, you'll learn how to work with Python's venv module to ... This change means that you've exited your virtual environment....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
It is an anti-pattern (I’d even say it’s anti-pattern to virtual environment usages in general), but people still depend on the behaviour, and sometimes it is even a useful hack. Like it is also an anti-pattern to install packages with managing it with Pipfile (
pipenv run pip install
), but we still allow that for the occasional edge cases, only inteerfere when the user explicit wants us to (pipenv clean
). It’s probably a good idea to follow the same pattern here, i.e. don’t actively overwrite (only showing errors), but provide a clear path to encourage it (with a command option, for example).i like the current implementation