So I’ve got a concept of virtualenv and how it might help make a new python version sandbox that doesn’t screw up your dependencies on your core OS by actually switching the python version. But how would one do this should a version of Python be deprecated by a project in the future?
yt-dlp deprecated all python versions below 3.8 (I believe) so I was forced to upgrade, but I did it the incorrect way and used PPAs and changed the system python version, which means my Blueman and Onboard are permanently broken.
What’s the correct way to make a completely separate “NEW Python” environment, sandboxed, and able to run pip to grab the latest yt-dlp bypassing the recent deprecation?
Are you trying to run a venv with a specific version or python?
If that’s the case, you can run mkvirtualenv -p /path/to/python
So if you need the system default python to be 3.7, and you need your venv to run 3.9, you can specify the versioned binary instead of /usr/bin/python. And whenever you’ve activated the venv, you will reference python 3.9 as just python.
Hope this helps!
P.S. Keep in mind that any pip packages you pull will only exist inside the virtualenv, thus requiring you to activate the venv before using youtube-dlp
I’d use a conda environments. Ryan used it for his video on openbb
Conda will make a directory and python for each new environment, so it can be heavy, but it doesn’t mess with your system’s python/pip.
I haven’t looked too much into virtual environments, but conda is what I was introduced to for work
If you want to go down the rabbit hole, you can also look into poetry environments
If you are using it for commercial purposes or in a business, I’d recommend miniforge. You could also use minconda, but just remember to set it to only use conda forge
I wrote a guide for how to setup miniconda a long time ago, but the instructions are the same for miniforge
I use my distro’s packaged version of yt-dlp, but in absence of that, instead of messing with PPAs / repos (deb or copr) / AUR or anything like that and especially with pip and other ways (like npm) that I find untrustworthy, I’d rather use nix package manager (nix-env).
This way, you get the nix-store paths and you avoid filling your /usr directories with potentially disrupting dependencies. In all fairness, I haven’t found myself using nix-env that much, because I just have everything I need in the main repos (not that I use a lot of software anyway), but I found myself using nix-env on Alpine from time to time (the community repo seems to not have a lot of stuff, which makes nix-env a godsent tool).
