3 ms·

alright, I will bookmark this and try this next time I want to play with a python project. OK, how would I include all of these under the same PATH regime? So

• whalesalad 3y ago
  To access 10 different commands at the same time, that is tricky but definitely doable. 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/ https://www.pgcli.com/) and httpx (https://www.python-httpx.org/ https://www.python-httpx.org/) Setup a main home for all your venvs: cd ~ mkdir venvs Go into this dir, and create your venvs and install the packages cd venvs python -m venv harlequin ~/venvs/harlequin/bin/pip install harlequin Now this binary is available at $ ~/venvs/harlequin/bin/harlequin Repeat for the rest cd ~/venvs python -m venv pgcli ~/venvs/pgcli/bin/pip install pgcli cd ~/venvs python -m venv httpx ~/venvs/pgcli/bin/pip install httpx Wash, rinse, repeat. Now you have all these binaries available and can alias them alias harlequin="~/venvs/harlequin/bin/harlequin" alias pgcli="~/venvs/pgcli/bin/pgcli" alias httpx="~/venvs/httpx/bin/httpx" This is a pain in the ass though and usually simple CLI tools like this do not collide with each other. So that is why I say install globally, or install into your "global junk drawer" virtualenv. 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.
  • gottoupvote 3y ago
    Sounds like something https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/ could help with.
  • pmarreck 3y ago
    You know, at this point in the complexity story, you're literally at (or beyond) the level of Nix complexity which is the very solution that everyone who engages with this level of tooling seems to be trying to avoid, and since Nix solves this problem already definitively without having to jump through all these hoops, why don't Python projects just use Nix? Then they could all be colocated on the same machine and all be accessible from the same PATH and all have their specific dependencies none of which would ever collide with each other! 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. https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf