Thanks to @adamw, who dared to suggest we try it, we now have a small patch for #virtualenv in #Fedora to enable creation of #Python 3.6 virtual environments.

Hence, you can use #tox to test your code on Python 3.6 to 3.15, without the need for nasty hacks -- https://github.com/tox-dev/tox/issues/3656

Supporting testing on 3.6 is important to us, as many developers targeting #RHEL 8 still need to support it. (Python 3.6 is the new Python 2.6.)

Anyway, test it out:
https://bodhi.fedoraproject.org/updates/FEDORA-2026-f4f2c6bb32
https://bodhi.fedoraproject.org/updates/FEDORA-2026-995bb86cb3

Learn how to easily migrate Python packages between virtual environments in Linux.

Step-by-Step Guide: https://ostechnix.com/migrate-python-packages-between-virtual-environments/

#Python #Pip #VirtualEnvironment #Virtualenv #Programming #Linux

I kind of irrationally #CodeGolf my #Makefile rules, but sometimes I sit down to straighten out something awkward that bugged me for years, and get kind of mad when I seem to have been the first to actually treat `make` like the tool it is instead of as a broken shell script runner.

This time it was #Python #VirtualEnv setup:

```
dep: .venv/bin/pip .venv/lib/*/site-packages/__pycache__

.venv/lib/%/site-packages/__pycache__: .venv/bin/pip requirements.txt
.venv/bin/pip install -Ur requirements.txt

%/bin/pip:
/usr/bin/virtualenv $*
```

(Yeah pretend those are tabs. Yeah that is make's worst wart.)

I even use `!#.venv/bin/python3` in my scripts and hey presto everything just works everywhere and I can focus on the actual code.

I'm curious what cases I'm ignoring or missing here. Non-install upgrades may deserve a target perhaps...

So, I'm tinkering a bit with #Django, and I wanted to run different Django versions on the /same/ virtual machine. Here `#virtualenv` helps only insomuch that it can seperate dev envs, but it all still shares the `~/.local/lib/python3.10/site-packages` folder.

(I can't imagine this problem hasn't been solved, but couldn't find anything online.)

I've resorted to overriding HOME: basically I wrote a `virtualenvenv` script that I source, and then I have the separation I want/need. 🔨

For some reason, since this morning, the #pip that I installed via #pipx does not work with my other #virtualenv setups anymore (it installs all packages in its own pipx venv instead of the currently active venv).

Has anyone else encountered this issue? It makes pip virtually (hoho) unusable!

#python #venv #virtualEnvironment

If I had the time and energy I would:

• Make a #ThonnyIDE plug-in to launch #JupyterLab from the Thonny GUI interface (using Thonny's #Python #virtualenv;
• Write some code to convert #geoDataFrames with a graphic attributes column into #py5 styled shapes;
• Make a search interface to my daily sketch-a-day sketches and fix the RSS.