pathetic piss kitten (@kitten)

pathetic piss kitten @kitten@elizabeth.cat

I hate python

1❤️1

pathetic piss kitten @kitten@elizabeth.cat

what the hell is a virtualenv

❤️1

theking killed the radio star @theking@mskey.nekomimi.party

@kitten iirc that's to fix the problem created by pip/modules/whatever they're called

pathetic piss kitten @kitten@elizabeth.cat

@theking they have a very interesting way of "solving" problems

❤️1👍1

Xerz 💗 @xerz@fedi.xerz.one

@kitten a miserable pile of

(really, it’s just like they tried to invent containers before they actually could, so they just did path/envvar trickery for Python-only stuff and called it a day)

Alba 🌸

@mildsunrise@tech.lgbt

@kitten a virtualenv is a folder that contains a bin/python, bin/pip, lib/site-packages...

using the bin/python of a virtualenv, your imports will look at lib/site-packages of that virtualenv

using the bin/pip of a virtualenv operates on the lib/site-packages of the virtualenv instead of the system's one

that way you can install the dependencies a project needs without interfering with the global python installation

Alba 🌸

@mildsunrise@tech.lgbt

@kitten for convenience, virtualenvs also come with a bin/activate script. sourcing that into your shell places the virtualenv's bin folder into your path, so you can do

pip install thing
python main.py

instead of

virtualenv/bin/pip install thing
virtualenv/bin/python main.py

Alba 🌸

@mildsunrise@tech.lgbt

@kitten also 'virtualenv' is how the original tool to create and manage these directories was called, but since then it has become deprecated in favor of the venv tool (invoked with 'python -m venv'). still the name 'virtualenv' has sticked as a way to refer to the general concept, regardless of which tool was used to create it

Jesse

⬆️➡️⬇️⬇️⬇️ 39c3 @jessew@mk.cpluspatch.com

@mildsunrise @kitten the problem that virtualenvs are meant to solve is package and Python version management

Python dependencies were traditionally managed by a system-wide package manager (pip), but that was annoying because then different programs that needed a different version of the same package exploded, so packages are installed inside the virtualenv directories now (each project has its own copy of the dependencies it needs)

If you've used Rust or Node.js, they have the same concept (node_modules and i forgor what the cargo folder is called)

pathetic piss kitten @kitten@elizabeth.cat

@jessew @mildsunrise except npm already manages that for me, I don't need to create my own virtualenv, deciding where to place it, or putting it in my path

Jesse

⬆️➡️⬇️⬇️⬇️ 39c3 @jessew@mk.cpluspatch.com

@kitten @mildsunrise yeah it's just an extra step because python didn't do it like this from the get-go

Jesse

⬆️➡️⬇️⬇️⬇️ 39c3 @jessew@mk.cpluspatch.com

@mildsunrise @kitten virtualenv essentially sets some shell environment variables to tell python "yo, look for packages in this directory instead of the default /usr/bin/whatever"

pathetic piss kitten @kitten@elizabeth.cat

@mildsunrise so I should just use devcontainers, got it

Alba 🌸

@mildsunrise@tech.lgbt

@kitten ...no, it makes little sense to use virtualenvs if your global installation is already unique to your project. if you're using a devcontainer you can skip the virtualenv entirely

ity [unit X-69] - VIOLENT FUCK @ity@estradiol.city

@kitten prefix/container for libraries

Klaus Frank @agowa338@chaos.social

@kitten the thing you want to use. Python in a folder, so that all of the dependencies related to that project are basically vendored.
However for some reason they still don't statically link the binaries so it will still randomly stop working.

That way for python the best approach to vendoring to this day is a docker container, sadly.

also all of the alternatives like pyenv and such have similar issues, especially if it should work cross platform as well...