#virtualenv — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #virtualenv, aggregated by home.social.
-
От Dependency Hell до изоляции: эволюция и внутреннее устройство виртуальных сред в Python
До 2007 года установка двух версий одной библиотеки на одном сервере была невозможной миссией. Появление virtualenv, а затем и нативного venv, изменило ландшафт Python-разработки навсегда. Но как именно работает этот механизм на уровне операционной системы и интерпретатора? Разбираем путь от копирования бинарников до современных симлинков, анализируем роль sys.path и реализуем собственный аналог 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 -
My final boss in solving this #Django on #Alpine container thing is getting #Apache/#WSGI (mod_wsgi) working. My container runs Apache fine, I suppose, if I don't supply it any site config - but once I do (i.e. in
/etc/apache2/conf.d), I'm gettingSegmentation fault core dumpederrors and reboots.
I'm assuming, as far as my config goes, I need to pointpython-hometo where my #virtualenv is, in addition topython-pathto where my Django site/app is (like I do on #Ubuntu since that does not enforce the use of venv yet). But that doesn't seem to be enough, so again, in addition toapache2,apache2-mod-wsgi, andapache2-utils(and perhapsmusl-devandgccin runtime other than just during build), what am I missing? -
671 - Descubre la herramienta que cambiará como usas Python
#uv es la herramienta perfecta para gestionar proyectos y dependencias de #python y que viene a sustituir a #pip #poetry #pyenv #virtualenv y otras
Como ya te he comentado en mas de una ocasión, la llegada de Rust, está suponiendo una auténtica revolución. Los desarrolladores apoyados en Rust se ha
-
Hey #Fedi, can you help me with a #Python environment pain-point?
TL;DR : I want global #virtualenv management
I've been using virtual environments for quite some time, but I might be missing some standard feature because switching env is a pain: I have to be in the right folder (where the venv dir was created) or manually configure a shell script.
Is there a tool that can provide me with the equivalent of ``envswitch envname`` regardless of the folder I'm in? -
After programming a good 2 months in #python finally found the tool #poetry which is quite similar to how #nodejs bundles libraries into a directory either locally or globally in the cache directory.
I have tried the other tools from #pyenv to #venv and/or #virtualenv. Where I thought they were used to deal with library dependency management only to realize that they are more like #nvm.
I did use #conda for some time, though preferred a python only solution. I do realize that poetry won't resolve all issues and might need to look into to containerization later on, though for the time period it looks like a good solution.
-
Using pyenv and pyenv-virtualenv to install Python and create a virtual environment on MacOS https://www.andreagrandi.it/posts/install-python-with-pyenv-and-pyenvvirtualenv-create-virtual-environment-with-specific-python-version-macos/
I keep referring to this blog post of mine a lot. I'm glad I took some time to note all my process so I can reuse it int he future (and hopefully it's useful for other people too)
-
Can you try installing it with `pipx` instead?
pipx will create a Python virtualenv just for that program, and install all of its dependencies into that virtual environment. It can then run independently of any system-level versions of those same packages that are installed *for the distro-shipped Python tools*.
The version pipx installs can be upgraded (or left alone) completely independently of OS updates.
-
Just tried the #uv #Python management tool. At first I thought: Oh no, not another Python package manager. But this one seems different. It combines all the pip-tools, #pyenv, #poetry, #virtualenv, etc in one.
And it's damn fast. This likely will stay with me for a while. -
Why is Python special in this regard? Many applications, whether written in Python, Perl, Ruby, or C etc, embed a particular version of a library because they either can't rely on it being available system-wide, or because they can't rely on the system-provided one being completely #compatible with their needs.
I find virtual environments an elegant solution to the problem, better than many other languages' solutions.
-
For Ubuntu, the deadsnakes repo can be used to install a bunch of other versions, or the pyenv tool can do it. There are other ways too.
Then, get used to using virtual environments for development (so you're not installing your project's dependencies globally, and you can't get conflicts).
For installing 3rd-party tools not in your OS, i.e. you're not hacking them, just using them, use `#pipx install --python python3.11 <pypi-name>`. pipx is in the system repos.
2/2
-
I guess I'll learn how to use #virtualenv and use Python 3.9? (or should I use #pyenv? #pyvenv? #venv? #virtualenvwrapper? #pipenv? Why are there so many of these things??)