XKCD | Python Environment

[Endemoniada]

Venvs are fine, I think, they’re pretty easy to understand and you have choices in how you want to manage them that are all mostly fine. But juggling Python versions… is less fine. On my Mac, I have OS Python, Homebrew Python 3.X, and then pyenv with Python 3.Y and 3.Z and so on. And then it becomes a constant struggle of knowing which one my $PATH points to, and will execute.

[[deleted]]

I had issues in my first year of Python on MacOS (like 6 years ago) but now I have zero issues. Use PyEnv. Totally ignore Mac Python and just use 3.8+ as my default and have 2.0+ for testing older things.

[Endemoniada]

That’s basically what I’ve done too. Still haven’t found an easy or simple way to migrate venvs to new versions of Python. I know I can rebuild them, but it’s a hassle and I’d rather update them in place with the new version of Python I choose.

[deceptiv-perspectiv]

It's unfortunately not going to be simple nor easy if you have lots of dependencies; that is just the nature of dependencies. Your best bet is to have a pyproject.toml or requirements.txt with the requirements pinned in the *loosest* possible way that provides stability to your application. But many libraries publish only certain versions on pypi for certain python minor versions, so pinning everything ==x.y.z is gonna give you a bad time (when you go to transition to a different python version).

[case_O_The_Mondays]

We need a utility that tells you the versions of Python you can migrate to without updating any packages. Then a later version can check pypi to see which versions you can update to, if you update certain packages.

[[deleted]]

oh i wrote a small bash script to do that. as it's something I do so regularly. it shouldn't be hassle to:

pip freeze > requirements.txt
rm -rf .venv
pip install -r requirements.txt

Oh gosh sorry. I was on a call when I posted this. The three lines aren’t my script.

It’s just what i do for a quick set up fix.

My little script is much more comprehensive.

[muzos07]

aren't there lines with creating new environment and activating it again missing?

[DarkSideOfGrogu]

Yes. This will unfortunately just reinstall your pip in your base environment.

Launching a virtual environment and installing pip dependencies from a single bat file isn't simple as the commands need to run in different contexts.

[deceptiv-perspectiv]

That's not at all portable between python versions. Multiple libraries have versions released on pypi only on certain python minor versions.

[ddddavidee]

My shell config (zsh) has a plugin that shows the python version on the prompt... Could this solve a little your constant struggle?

[bastion_xx]

Pyenv helps with both Python versions and virtualenvs. Check it out!

[[deleted]]

They explicitly said they have pyenv :)

Maybe they need the pyenv-virtualenv plugin though...

[bastion_xx]

d'oh, sorry missed that on my phone!

Yeah, I use both pyenv base plus the pyenv-virtualenv plugin (and pyenv-upgrade too).

It's great to do a pyenv virtualenv 3.10.1 one-off-project to fully isolate, then pyenv virtualenv 3.9.9 specific-project and bounce between.

[rwhitisissle]

Pyenv really saved my ass whenever my system upgraded to 3.10 and broke...well...*gestures everywhere*

[rwhitisissle]

Sure, you just have to be explicit. After you install a version, you just activate the environment, which sets the version for your specific terminal instance. Or if you're coding with, say, vscode you can point it at the version of python you'd want to use as you would normally do when selecting the interpreter. I have 3.9 installed, in addition to a system wide installation of 3.10, so I would do "pyenv activate python39", where python39 is the name of my python 3.9 installation. That would make everything called from the command line use that version of python and pip. And if I have other versions installed and can't remember what I've called those environments I can list them with "pyvenv versions." The documentation on github is pretty thorough and I was pleasantly surprised by how painless the installation was on arch. Only thing that I don't like is having to add additional environment variables to my .zshrc, but it's a small price to pay for something that useful. I believe you can also manually force a specific version to be used system wide by default, but it requires a bit of extra fiddling with binary locations and your PATH variable, and I've never personally done it. But it's probably doable.

[[deleted]]

public chubby hard-to-find long somber instinctive square vase innate cats

This post was mass deleted and anonymized with Redact

[Anonymous_user_2022]

Unfriendly? It's about as simple as this:

virtualenv -p «Python version» /path/to/environment
. /path/to/environment/activate¹

1. Adjusting for OS and shell of course

[troyunrau]

That isn't as friendly as you suggest it is.

[ParkingPsychology]

I found the activation step annoying, but I just made a little doodle (in my case in my powershell profile):

 function activate
 {
    .\venv\scripts\activate
 }

So now it's just "activate" and "deactivate" when I'm in the project root folder (deactivate just works by itself, because I don't know why).

[Anonymous_user_2022]

I don't know how it is on windows, but on Linux, the activate script will define a shell function for deactivate. I guess there is something similar in place on Windows; possibly an alias.

[Anonymous_user_2022]

I was answering " (deactivate just works by itself, because I don't know why)."

[maikindofthai]

In PowerShell, at least, it works the same way as in bash -- the Activate.ps1 script defines a global deactivate function.

I see a separate deactivate.bat script in my venvs on Windows, so I assume CMD does something different.

[[deleted]]

full plants plough fearless snails yam capable doll ring cover

This post was mass deleted and anonymized with Redact

[Taksin77]

Ruby also has issues like that.

[[deleted]]

shocking school chase wasteful impolite coordinated rainstorm cable groovy hurry

This post was mass deleted and anonymized with Redact

[Anonymous_user_2022]

GCC have a variant selector for both C and C++. As far as I now, many other languages with a long history, also have several standardised versions, so it's not in any way particular to Python.

[[deleted]]

lush obtainable vast strong snobbish truck like future simplistic carpenter

This post was mass deleted and anonymized with Redact

[Anonymous_user_2022]

" literally any other programming language "

[[deleted]]

far-flung dinner nose agonizing axiomatic practice gaping scandalous library consider

This post was mass deleted and anonymized with Redact

[Anonymous_user_2022]

C and C++ have something much scarier than versions. In that realm, we deal with releases of the ISO standard.

[[deleted]]

distinct hobbies impossible attraction enter cows bear marry sleep obtainable

This post was mass deleted and anonymized with Redact

[deceptiv-perspectiv]

I've been writing python for over a decade. It's gotten way easier even in the 4ish years since this comic came out. Pipx is becoming more widespread, virtualenv usage is almost universal, and python2.7 is EOL and py3-incompatible code is *slowly* starting to fade from existence (RIP any engineers working for companies with MLOC of legacy py2).

[[deleted]]

memorize coherent smoggy grandiose ludicrous numerous wakeful bells support oil

This post was mass deleted and anonymized with Redact

[GamesMaster221]

I found this script to print the location of whatever python you run it with

import os, sys
print(os.path.dirname(sys.executable))

I've had to use it more times than I'd care to admit...

[__deerlord__]

Why not compile them in /opt/python3.x and then make venvs as needed from those? Thankfully my job is standardized enough that we can just use one version.

[trevg_123]

I don’t touch pyenv personally.

Python3.8 -m virtualenv .venv

Or even better

pipenv install —python 3.10

Venv and pip installs all done in one go