3 ms·

And this works with every existing Python project out there? What about `requirements.txt` projects?

whalesalad 3y ago
requirements.txt is just a list of packages for pip. It doesn't even need to be called requirements.txt, it could be called poopoopeepee.txt. That name is just a convention. 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, source venv_directory/bin/activate pip install -r requirements.txt or, skip the convenience and use the binary directly: venv_directory/bin/pip install -r requirements.txt 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 cd /srv/app /srv/venv/bin/pip install -r requirements.txt Then to invoke this with the correct runtime, it is as easy as /srv/venv/bin/gunicorn ... 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: /srv/application-foo/app - the codebase (ie, the github repo) /srv/application-foo/venv - the corresponding virtualenv /srv/application-bar/app /srv/application-bar/venv 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`
- pmarreck 3y ago
  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 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.
  - 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.
    - 3y ago
nerdponx 3y ago
It works for installing dependencies from Pip, so yes, unless that Python project is doing something bizarre that it shouldn't be doing. It's functionally identical to node_modules or Ruby Bundler or Perl local::lib. It's so weird to me that people continue to hate Python for a problem that literally every programming language has had since shared libraries were invented.

requirements.txt is just a list of packages for pip. It doesn't even need to be called requirements.txt, it could be called poopoopeepee.txt. That name is just a convention. 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, source venv_directory/bin/activate pip install -r requirements.txt or, skip the convenience and use the binary directly: venv_directory/bin/pip install -r requirements.txt 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 cd /srv/app /srv/venv/bin/pip install -r requirements.txt Then to invoke this with the correct runtime, it is as easy as /srv/venv/bin/gunicorn ... 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: /srv/application-foo/app - the codebase (ie, the github repo) /srv/application-foo/venv - the corresponding virtualenv /srv/application-bar/app /srv/application-bar/venv 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`

pmarreck 3y ago
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 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.
- 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.
  - 3y ago

nerdponx 3y ago

It works for installing dependencies from Pip, so yes, unless that Python project is doing something bizarre that it shouldn't be doing. It's functionally identical to node_modules or Ruby Bundler or Perl local::lib. It's so weird to me that people continue to hate Python for a problem that literally every programming language has had since shared libraries were invented.