3 ms·

Use your OS to install the stock Python and the stock setuptools, wheel, and virtualenv Python packages. Then make a virtualenv for every single Python applicat

Use your OS to install the stock Python and the stock setuptools, wheel, and virtualenv Python packages. Then make a virtualenv for every single Python application (virtualenv ./some app/). Then make a requirements.txt file with the pip packages you need and their version numbers and install with ./someapp/bin/pip install -r requirements.txt. If you do something bad, rm -r ./someapp/ and start over.

jnwatson 6y ago
I disagree to use the stock OS for any part of Python you're using as a regular interactive user. The easiest and safest way is to use a Python vendoring tool like pyenv to install a Python version of whatever you need. After that you can use regular pip and virtualenv without any special paths, and the environment is local to the user, so you're unlikely to interfere with another user's environment. Pyenv is not unlike nvm for Node. Python moves too fast to expect the OS distributions to keep up.
- pmontra 6y ago
  To be fair, any language (and database) moves faster than distributions. I use language package managers or docker for Ruby, Python, PHP, Node, Elixir, PostgreSQL and MySQL. I recommend asdf to support multiple languages and databases in the same project.
- peterwwillis 6y ago
  I've been a regular Python user for a decade and every Python app I've ever used has worked on stock Python. And vendor builds often ship with patches that make it work better on the OS in question. But I can see how devs often want bleeding edge releases. From a stability, reliability, and CI/CD performance standpoint, I would discourage building your own Python. Things break more the more often your base version changes.
mmmpetrichor 6y ago
It's not necessarily easy to install "stock python". e.g. installing python 3.7 or newer on ubuntu requires quite a bit of initial setup. You'll be required to install a ton of apt system dependencies, then add a custom system apt package index (ppa), then install it from the new repository and hope you managed to get all required dependencies. I failed several times in a row last time before I got it working, after trying 2 different methods.

jnwatson 6y ago

I disagree to use the stock OS for any part of Python you're using as a regular interactive user. The easiest and safest way is to use a Python vendoring tool like pyenv to install a Python version of whatever you need. After that you can use regular pip and virtualenv without any special paths, and the environment is local to the user, so you're unlikely to interfere with another user's environment. Pyenv is not unlike nvm for Node. Python moves too fast to expect the OS distributions to keep up.

pmontra 6y ago
To be fair, any language (and database) moves faster than distributions. I use language package managers or docker for Ruby, Python, PHP, Node, Elixir, PostgreSQL and MySQL. I recommend asdf to support multiple languages and databases in the same project.
peterwwillis 6y ago
I've been a regular Python user for a decade and every Python app I've ever used has worked on stock Python. And vendor builds often ship with patches that make it work better on the OS in question. But I can see how devs often want bleeding edge releases. From a stability, reliability, and CI/CD performance standpoint, I would discourage building your own Python. Things break more the more often your base version changes.

mmmpetrichor 6y ago

It's not necessarily easy to install "stock python". e.g. installing python 3.7 or newer on ubuntu requires quite a bit of initial setup. You'll be required to install a ton of apt system dependencies, then add a custom system apt package index (ppa), then install it from the new repository and hope you managed to get all required dependencies. I failed several times in a row last time before I got it working, after trying 2 different methods.