5 ms·

What is the recommended installation & version management approach to Python on MacOS these days? Install directly from python.org? Homebrew? Conda?

peanutbuterjly 4y ago
I like pyenv
- claytonjy 4y ago
  Pyenv works well, I just wish Poetry did that for me. Instead Poetry will gladly ignore a set pyenv unless you force it to pay attention.
  - Hackbraten 4y ago
    My workaround for that is to initialize every checked-out copy like so: pyenv install -s pyenv exec pip install poetry pyenv exec poetry install That incantation goes into my README.md. Inconvenient, but I’ve come to accept it. I only need to run it after initial checkout and when the .python-version changes.
    - claytonjy 4y ago
      Interesting! I like managing poetry at the user level with pipx, so my usual incantation is pyenv local 3.11.0 poetry init poetry env use $(pyenv which python) poetry install
Hackbraten 4y ago
I’ve settled for pyenv and poetry for my projects. As a former Homebrew maintainer, allow me to stress another thing: Don’t use your system’s (or even your system-level package manager’s) Python environment for your Python projects. That Python environment isn’t for you. It exists primarily for one single reason: to make other packages work that happen to depend on Python. The same goes for Node.js, Ruby and other fast-evolving platforms. Now, if you _do_ use that environment, the packaging police isn’t exactly coming for you. Just be aware that maintainers are free to version-bump or even remove the environment at any time without notice. That’s why you’re going to be happier and safer if you use *env- (pyenv, nodenv, …) managed installations.
- superkuh 4y ago
  >That Python environment isn’t for you. This is a relatively new and dangerous way of thinking about operating systems. Due to the massive futureshock of libs rapidly changing under-foot people have had to switch to containerization as a mitigation. And now people have been containerizing so long they are starting to believe it is the proper way to do things. It's not. Giving up the idea of an operating system with system libraries is very bad. The idea that you have to set up an entirely new lib environment to run every single script is absurd and it has dire consequences for software longevity and portability. With no more OS system as a base an OS is fractured into literally innumerable possibilities. Gone is the idea of a distro being the same for everyone using it. Gone is the ability to just install things. And we're left with a pile of containers that make debugging things when they go wrong even harder. Nix is taking this concept to the extreme and absurd, but using pyenv for every script is almost as bad. pyenv is not version management approach to Python. It's a bandaid that doesn't address the actual issue.
  - Hackbraten 4y ago
    > This is a relatively new and dangerous way of thinking about operating systems. One could as well say: this is a response to faster-than-ever evolving platforms. > Giving up the idea of an operating system with system libraries is very bad. Good point. I don’t like the situation either. I’m not sure there’s a good remedy. For example, how are system package maintainers supposed to know that your personal script is now ready to migrate, so they can finally bump system Python? > using pyenv for every script is almost as bad. pyenv is not version management approach to Python. It's a bandaid that doesn't address the actual issue. Not sure if I’m understanding you correctly here. You’re saying that using pyenv for every script is bad. Are you against venvs, too? Because you could apply a similar argument to those.
  - wheelerof4te 4y ago
    This x100. If your project requires dozens of installed libraries to use even it's base features, that tells me a lot about you and your project. Mainly, it tells me you haven't thought about stability and the future of your application.
dec0dedab0de 4y ago
I use pipenv, which will use pyenv to automatically install a version of python if i dont have it. I know pipenv caught a lot of flack a while ago because KR tried to push it out before it was ready, but I like it.

peanutbuterjly 4y ago

I like pyenv

claytonjy 4y ago
Pyenv works well, I just wish Poetry did that for me. Instead Poetry will gladly ignore a set pyenv unless you force it to pay attention.
- Hackbraten 4y ago
  My workaround for that is to initialize every checked-out copy like so: pyenv install -s pyenv exec pip install poetry pyenv exec poetry install That incantation goes into my README.md. Inconvenient, but I’ve come to accept it. I only need to run it after initial checkout and when the .python-version changes.
  - claytonjy 4y ago
    Interesting! I like managing poetry at the user level with pipx, so my usual incantation is pyenv local 3.11.0 poetry init poetry env use $(pyenv which python) poetry install

Hackbraten 4y ago

I’ve settled for pyenv and poetry for my projects. As a former Homebrew maintainer, allow me to stress another thing: Don’t use your system’s (or even your system-level package manager’s) Python environment for your Python projects. That Python environment isn’t for you. It exists primarily for one single reason: to make other packages work that happen to depend on Python. The same goes for Node.js, Ruby and other fast-evolving platforms. Now, if you _do_ use that environment, the packaging police isn’t exactly coming for you. Just be aware that maintainers are free to version-bump or even remove the environment at any time without notice. That’s why you’re going to be happier and safer if you use *env- (pyenv, nodenv, …) managed installations.

superkuh 4y ago
>That Python environment isn’t for you. This is a relatively new and dangerous way of thinking about operating systems. Due to the massive futureshock of libs rapidly changing under-foot people have had to switch to containerization as a mitigation. And now people have been containerizing so long they are starting to believe it is the proper way to do things. It's not. Giving up the idea of an operating system with system libraries is very bad. The idea that you have to set up an entirely new lib environment to run every single script is absurd and it has dire consequences for software longevity and portability. With no more OS system as a base an OS is fractured into literally innumerable possibilities. Gone is the idea of a distro being the same for everyone using it. Gone is the ability to just install things. And we're left with a pile of containers that make debugging things when they go wrong even harder. Nix is taking this concept to the extreme and absurd, but using pyenv for every script is almost as bad. pyenv is not version management approach to Python. It's a bandaid that doesn't address the actual issue.
- Hackbraten 4y ago
  > This is a relatively new and dangerous way of thinking about operating systems. One could as well say: this is a response to faster-than-ever evolving platforms. > Giving up the idea of an operating system with system libraries is very bad. Good point. I don’t like the situation either. I’m not sure there’s a good remedy. For example, how are system package maintainers supposed to know that your personal script is now ready to migrate, so they can finally bump system Python? > using pyenv for every script is almost as bad. pyenv is not version management approach to Python. It's a bandaid that doesn't address the actual issue. Not sure if I’m understanding you correctly here. You’re saying that using pyenv for every script is bad. Are you against venvs, too? Because you could apply a similar argument to those.
- wheelerof4te 4y ago
  This x100. If your project requires dozens of installed libraries to use even it's base features, that tells me a lot about you and your project. Mainly, it tells me you haven't thought about stability and the future of your application.

dec0dedab0de 4y ago

I use pipenv, which will use pyenv to automatically install a version of python if i dont have it. I know pipenv caught a lot of flack a while ago because KR tried to push it out before it was ready, but I like it.