The state of #security these days: #Python #virtualenv package now includes SHA256 sums of their bundled wheels, declaring that it protects against "supply-chain compromise". Because obviously there are so many attack vectors that permit you to alter a .whl file but not the .py file in the same directory.

No, I'm not saying verifying checksum makes no sense, because indeed it can save some pain if fs is damaged somehow. However, calling this a "security" feature is a misnomer at best, and openly giving people false sense of security at worst.

От Dependency Hell до изоляции: эволюция и внутреннее устройство виртуальных сред в Python

До 2007 года установка двух версий одной библиотеки на одном сервере была невозможной миссией. Появление virtualenv, а затем и нативного venv, изменило ландшафт Python-разработки навсегда. Но как именно работает этот механизм на уровне операционной системы и интерпретатора? Разбираем путь от копирования бинарников до современных симлинков, анализируем роль sys.path и реализуем собственный аналог venv.

https://habr.com/ru/articles/1013512/

#python #virtualenv #poetry #pip #venv

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. 🔨

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.