OK, how would I include all of these under the same PATH regime?
So for example say I want to run this project from a commandline location elsewhere... I'd only be able to have one venv activated at the same time in the same session, right?
I guess that's part of my issue with this. I want to be able to access 10 different Python projects' commands from the same command line at any time.
First thing that comes to mind, you can use aliases.
To keep it simple, lets use 3 examples instead of 10: harlequin (this project), pgcli (https://www.pgcli.com/) and httpx (https://www.python-httpx.org/)
Setup a main home for all your venvs:
cd ~
mkdir venvs
cd venvs
python -m venv harlequin
~/venvs/harlequin/bin/pip install harlequin
$ ~/venvs/harlequin/bin/harlequin
cd ~/venvs
python -m venv pgcli
~/venvs/pgcli/bin/pip install pgcli
cd ~/venvs
python -m venv httpx
~/venvs/pgcli/bin/pip install httpx
alias harlequin="~/venvs/harlequin/bin/harlequin"
alias pgcli="~/venvs/pgcli/bin/pgcli"
alias httpx="~/venvs/httpx/bin/httpx"
Meanwhile, for actual projects that you are developing on, those would have their own isolated venv.
I have a junk drawer venv where I install tools like this. If something goes wrong, it is as simple as rm -rf the venv and make a new one. And then I have isolated ones for each of the actual systems I maintain. Again, I use pyenv for this to make it a little easier to manage in conjunction with their specific python versions such that I do not ever interact with my distribution's Python. This is cross platform so it works across mac, linux etc. Very easy workflow, isolated, safe, can get blown away and recreated in a heartbeat.
Like, you're LITERALLY making a FANTASTIC argument for Nix usage in the Python ecosystem, here. In fact I'm going to bookmark this conversation now because of how ridiculously complicated your answer is compared to just using Nix.
Here's the Nix whitepaper. It's 14 pages or so. Read it on your next lunch break.
You could do `for line in requirements.txt, pip install <line>`. They are ostensibly the same. It is not a magical lockfile. It is unix. It is just a list if packages. If you are in a virtualenv, you will be fine.
either activate the venv,
or, skip the convenience and use the binary directly: virtualenv activation just sets the $PATH to refer to those binaries. you can use them directly.the production deployment for my core python app lives in /srv/app, the venv lives in /srv/venv
To update packages on the system, it is as simple as
Then to invoke this with the correct runtime, it is as easy as In this example I am running the gunicorn application server. This is running the specific gunicorn version installed into my virtualenv.The name `/srv/venv` is my decision. You can call that whatever you want and put it wherever you want. For instance, if you have two projects called application-foo and application-bar, you can have the following:
Some people will even put their venv dir inside of their source tree and exclude it from git (add to .gitignore), but I do not like this approach because my deployments destroy the app dir and unzip the build into that location on each deploy.I cannot speak for every python-based project (distinction from pip package) out there. A lot of people do not know what they are doing, open source is literally all the rope to hang yourself with. Anything is possible, and people without engineering experience will glue things together without understanding how they work.
If you are installing something via pip, then yes, you can create N virtualenvs and use them however you want. They are 100% isolated environments.
If you are using homebrew, apt-get, dnf/yum, arch etc... then those are going to obviously vary from distro to distro and that is outside the scope of this discussion.
I try to stick to Python's native tools as much as possible. Using a distribution package is going to cause issues, for sure. IE, don't install `apt-get install python-pil`, use a virtual environment and `pip install PIL`