10 ms·

just spent about 4 hrs getting Python 2 and pip setup on my Mac. Any time I have the misfortune of needing to use python I get cold sweats at the thought of the

by warent 5y ago

just spent about 4 hrs getting Python 2 and pip setup on my Mac. Any time I have the misfortune of needing to use python I get cold sweats at the thought of the environment stuff. Why is this still such a massive problem?

blondin 5y ago
i sympathize. the problem is apple. they are (understandably) refusing to ship an up-to-date global python interpreter with macOS. not only that, they aren't removing the default 2.7 that they ship. macOS Big Sur ships Python 2.7. ha. ha. ha. none of the proposed "virtual environments" solutions are going to rescue you when you operate globally at the OS-level and not in a sandbox. been there.
- wutbrodo 5y ago
  > they are (understandably) refusing to ship an up-to-date global python interpreter with macOS What is the understandable reasoning?
  - mbreese 5y ago
    It's pretty common to have kept `/usr/bin/python` as Python2. This is the most conservative option and won't break anything that's already running. Anyone who is using Python currently will have already installed Python 3 (or knows how to do this), and is probably using `#!/usr/bin/env python3`. As an OS vendor with many (many...) systems in the wild, you don't want to switch Python versions on people unexpectedly. Especially when it's still pretty painless to keep python2 around even if there is an installed python3. For anyone that's still using python2 (as a nearby comment mentioned), there is now at least a warning to avoid using the default Python 2.7 (/usr/bin/python). For an OS vendor, this transition takes a long time... but at least it's in process.
    - wutbrodo 5y ago
      Oh, sure, it's definitely not a good idea to change what the unqualified python binary refers to. But I interpreted "refusing to ship an up-to-date global python interpreter with macOS" as meaning that Python3 isn't shipped at all, with the binary name "python3"). Is that the case? If so, I still don't understand the reasoning.
      - mbreese 5y ago
        I don’t think anything in macOS (the base OS) requires Python, does it? If not, then, I don’t see why Apple would want to ship any Python with the OS. Let people install the Python version they want and then the users will have to maintain it.
        wutbrodo 5y ago
        The comment I asked rhe question of said: > the problem is apple. they are (understandably) refusing to ship an up-to-date global python interpreter with macOS Ie the claim is that it's causing a problem for users. I don't have an opinion about this point, but it is the premise of my question.
- JimDabell 5y ago
  > not only that, they aren't removing the default 2.7 that they ship. Yes they are: $ python WARNING: Python 2.7 is not recommended. This version is included in macOS for compatibility with legacy software. Future versions of macOS will not include Python 2.7. Instead, it is recommended that you transition to using 'python3' from within Terminal. Python 2.7.16 (default, Aug 30 2021, 14:43:11) [GCC Apple LLVM 12.0.5 (clang-1205.0.19.59.6) [+internal-os, ptrauth-isa=deploy on darwin Type "help", "copyright", "credits" or "license" for more information. >>>
- oefrha 5y ago
  1. macOS ships a /usr/bin/python3 that is up-to-date at the time of the feature freeze of a major macOS release, e.g. macOS 11 ships Python 3.8.2 from February 2020. 2. /usr/bin/python being a symlink for python2.7 is entirely consistent with PEP 394 recommendations, especially the version before June 2019: https://raw.githubusercontent.com/python/peps/214736457f6d61a98c14915316056c2d1076cc3b/pep-0394.txt https://raw.githubusercontent.com/python/peps/214736457f6d61... * Unix-like software distributions (including systems like Mac OS X and Cygwin) should install the ``python2`` command into the default path whenever a version of the Python 2 interpreter is installed, and the same for ``python3`` and the Python 3 interpreter. * When invoked, ``python2`` should run some version of the Python 2 interpreter, and ``python3`` should run some version of the Python 3 interpreter. * If the ``python`` command is installed, it should invoke the same version of Python as the ``python2`` command (however, note that some distributions have already chosen to have ``python`` implement the ``python3`` command; see the `Rationale`_ and `Migration Notes`_ below). The 2019 update https://github.com/python/peps/commit/ae932bd6fd2c493d7d64ce328a5293bac4c48884 https://github.com/python/peps/commit/ae932bd6fd2c493d7d64ce... allowed more flexibility, but the old handling is still entirely okay.
ArchD 5y ago
No such problems on Linux, which is free and open-source. I think 'open-source' is the key.
- Godel_unicode 5y ago
  I think you mean you don't have such problems on Linux, there are plenty of people who trip over the fact that the default python on RHEL<= 7 was comically old and unintuitive to update... https://www.ibm.com/support/pages/work-around-frustrating-python-3-install-rhel7 https://www.ibm.com/support/pages/work-around-frustrating-py... https://unix.stackexchange.com/questions/468620/how-to-change-python-default-version-from-2-7-to-3-7-on-rhel-7 https://unix.stackexchange.com/questions/468620/how-to-chang...
  - ArchD 5y ago
    You are comparing apples and oranges, obviously. Perhaps some people are just unconsciously too enamored with apples. OP's problem was not configuring default Python version as in your second link. Your first link is about some IBM stuff, and IBM is proprietary, so no comments there. Neither was OP's problem about setting up Python on an old version of the Mac OS. In any case, on old RHEL, you can just do something like this: https://www.2daygeek.com/install-python-3-on-centos-6/ https://www.2daygeek.com/install-python-3-on-centos-6/ Installing Python on Linux is much easier than you're trying to say. For the the love of apples.
    - Godel_unicode 5y ago
      Configuring the default python, also referred to as installing a new Python, is exactly what OP was doing. The process in the supplied link, which is the same as the process you weirdly called IBM proprietary even though it has nothing to do with IBM, is essentially the same as the process on MacOS. Realize that the OS python is not what you want, enable a non-default package repository with a few shell commands, install Python. Prejudice about anything to do with Apple aside, glad to see we agree that RHEL and MacOS have similar install processes.
NelsonMinar 5y ago
Using Python 2 is a big part of the problem. Modern Python 3 is a lot nicer. Also you're much better off if each Python project has its own virtual environment using the venv module.
- deleted 5y ago
  [deleted]
- yjftsjthsd-h 5y ago
  While I also quirked an eyebrow at the exact version, is 3 better at package management & environments?
  - lacker 5y ago
    It's still a mess, honestly. They tried to standardize on venv but since it doesn't deal well with Python libraries that depend on non-Python components, conda is still better for many purposes.
    - anakaine 5y ago
      Except when Conda plays hard to get, like in any corporate environment with connection inspection, custom root CAs, or not quite admin privileges. Then Conda is an absolute dog and hard to work with, yet regular old python is fine.
    - isoprophlex 5y ago
      Can you give a specific example? I've had nothing but pain with conda in mixed linux/mac/win environment at work, and actively worked to get it deprecated. We're on plain venvs now, with the occasional setup.py Curious if I missed some useful case for it. - very slow dependency resolvers - using conda in docker is annoying - the worst thing: inconsistencies in downloading binaries and other resources between win/mac/linux when installing packages - conda insisting on messing with bashrc to run their 'activate' crap - beware the fool who runs 'sudo conda whatever' on a multiuser system
odonnellryan 5y ago
What are you trying to do? It generally is not a problem unless you are using old or obscure packages. Sure some projects need those things, probably a lot of them, but I don't think that is really pythons fault. Not that this couldn't be done better in python. What issues did you encounter?
NikolaeVarius 5y ago
I dont know how its actually possible to spend 4 hours getting lyton2 and pip setup at all. The issues deal with managing upgrades, not initial setup
i_like_apis 5y ago
4 hours? Yeesh. Here's how to do it in 5-10 minutes. Use pyenv to install any python version and pyenv-virtualenv to manage virutal environments. https://github.com/pyenv/pyenv https://github.com/pyenv/pyenv https://github.com/pyenv/pyenv-virtualenv https://github.com/pyenv/pyenv-virtualenv
- nomel 5y ago
  For me, pyenv on Mac is about 15 minute compile time with a bunch of environment variables required to make sure tkinter works properly.
  - heavyset_go 5y ago
    brew install pyenv
  - uranusjr 5y ago
    The compile time depends largely on dependencies. If you have OpenSSL, zlib, and whatnot pre-installed (either via Homebrew or self-compiled and specified with environment variables), the compile time is close to 5 minutes. If you don’t, by default pyenv (actually python-build) compiles all those from scratch, and can easily spend north of 20 minutes (mostly for OpenSSL).
  - stonecharioteer 5y ago
    Use miniconda. It's much better.
    - nomel 5y ago
      The licensing is not compatible with my companies legal team.
- rlayton2 5y ago
  Anaconda is also great for beginners - GUI, lots of normal packages precompiled (also numpy, scipy, pandas, scikit-learn). If you do the full install, it comes with lots of packages pre-loaded.
jnwatson 5y ago
Please enough of this. Trying spending 2 minutes googling it. Hint: pyenv
- alwillis 5y ago
  Took the words out of my mouth. Let’s not over complicate things.
- e3bc54b2 5y ago
  virtualenv, pyenv, venv.. I'm sure they all work well, but for a newbie, the sheer choice is a killer, especially when they all work almost same, but not quite. Now compare that with cargo or npm and the canonical way makes newbie upbringing SL much easier.
- DrOctagon 5y ago
  I wanted to install python on a new Mac last night and just couldn’t get up and running. Closest I got was with using anaconda but although I could get the right env in the terminal I couldn’t get either paycharm or vscode to pick up the correct interpreter/packages etc. I’d almost guarantee there was something simple I was missing but for someone not familiar with the ecosystem getting python set up to do more than just hello world is a shitshow.
- em500 5y ago
  If you spend 2 minutes googling it (or even just reading HN comments here), you'll get various people recommending venv, pyenv, poetry, conda, pyflow and probably a whole bunch of deprecated stuff, where it's totally unclear to outsiders which one to use.
  - NathanOsullivan 5y ago
    Fwiw if you are an outsider, having gone through this exact issue myself recently start with venv: https://docs.python.org/3/library/venv.html https://docs.python.org/3/library/venv.html It is a standard library module and serves as the base functionality, most the other things you list are third party tools that build on the venv concept in various ways. Once you grok venv, you will be in a position to understand if those tools can provide value to your particular situation.
guskel 5y ago
If you use pyenv, it shouldn't be that difficult.
fiddlerwoaroof 5y ago
Interesting, I don’t use Python much anymore, but my project setup was always something like: virtualenv -p interpreter venv source venv/bin/activate pip install . . . These days, I just use nix
- shakna 5y ago
  Replace the first line with python3 -m venv venv And you have the current state of things.
anothernerd2 5y ago
Install miniconda, it’s amazing. Takes roughly 30 seconds to install. After using conda I’ve never had environment issues
forgingahead 5y ago
Python dependency management is rubbish, and many python projects have incomplete or missing requirements.txt files. I dislike Python as well (why on earth is whitespace relevant??) but unfortunately if you want to tinker with any of the newest deep-learning projects, you'll need python. I use Anaconda for package management on Ubuntu, which helps a lot, but it's still not my preferred programming language.
- saltyfamiliar 5y ago
  > why on earth is whitespace relevant?? To eliminate the need for braces and semicolons, of course. It's part of what makes python so easy to read and write. Is it really such a problem? I honestly can't imagine disliking python. It's my goto for anything where performance doesn't matter due to its unmatched ergonomics and vast libs. Golang comes close but for some reason having to implement really common and basic things yourself is part of the language's design philosophy. Plus it's compiled so you can't just drop into the interpreter for a slick one-liner. What's your preferred quick and dirty scripting/programming langage?
  - forgingahead 5y ago
    I prefer Ruby for quick scripting - in my opinion it beats Python in readability (sugarcoating handlers/hiding guts like not needing self littered everywhere), and seems to have more logical consistency in calls (eg: array.append(element) but len(array) in Python vs. array.append(element) and array.length in Ruby, amongst many other things). It's definitely a preference, and Python has a lot of library support that the Ruby community doesn't (yet, hopefully), but grandparent's comment about headaches setting up Python with a simple project are pretty common. Rarely do I encounter a Python project that "just works" - If your setup isn't exactly the same as the repo owner, and often even they don't even know why their setup is the way it is, then there's often a lot of fiddling and package adjustments needed. Not a deal breaker normally, but enough to make it more painful to quickly drop in and start experimenting with.
tus89 5y ago
Sounds more like the misfortune of using a Mac.
wenc 5y ago
I use the Anaconda distribution. I can create environments containing any version of Python, like this: conda create -n myEnv python=2.7 conda activate myEnv I think the problem is that unless someone already knew Python, they probably wouldn't understand environments, so their first thought would be to somehow install another version of Python and replace the system Python, or to use a switcher to switch between versions. That would be my first intuition too. (and I believe that's how Ruby works, via RVM). But Python works just a little bit differently in that it advocates for the use of its own environments to isolate dependencies. I'll have to admit it is not super intuitive (I already have a system package manager (apt, brew, etc.) and I have Docker containers -- why do I need another yet another environment?) but over time I've just accepted it for what it is. It's a Python convention.
- lacker 5y ago
  I mean, conda is installing another version of Python, and it provides a switcher to switch between environments. Conda and rvm are very similar to use.
lmm 5y ago
1. Python has a low barrier to entry and is a popular first language, so most users don't realise how bad it is. 2. Python was originally popular with old-school sysadmins, Debian types, and a lot of its package management is based around that philosophy of carefully hand-tended servers shared by multiple users.
- iamcreasy 5y ago
  Care to elaborate on what is bad? How bad are they compared to other languages? (Assuming you are always accepting some tradeoffs when moving from one eco system to another)
  - sergiomattei 5y ago
    It's painfully archaic compared to languages that have all this sorted out. Pip is a recipe for disaster, indicated by the huge amount of churn in the Python packaging sphere. It's constantly the worst part of my day whenever I pick a Python project up. Conflicting dependencies, non-deterministic installs, etc. I used to cope with this crap fest until I tried Elixir and experienced the beauty of modern package management and build tools. One tool, Mix, that handles task running and dependency management with a proper resolver. I honestly think even Node has a better package management and tooling story. Also: virtual environments are a hack and a pain. Python is moving forward in this aspect with the recent PEP for the pypackages folder, but we're still a long way from adoption. All of this stuff is painful for beginners. Virtual environments might seem easy to us, but I've had ridiculous amounts of trouble explaining why they're necessary to beginner developers. Then you have to explain `poetry` or `pip freeze`. Even I have trouble coming back to older projects of mine and I'm an experienced Pythonista: I usually waste an hour or two trying to sort the pip dependencies out with whatever conflicts the resolver comes up with this time. Python package management is not okay, we're all just used to coping with it. Other languages put it to shame.
    - cerved 5y ago
      Package management is pretty fubar for in every language I've tried but python is one of the worst
deleted 5y ago
[deleted]
cdrini 5y ago
Folks have given a number of good options here, but I thought I'd mention some other ones in case they're helpful for your use case. 1) docker! If you only plan on tinkering with something and don't want to install a bunch of random things on your machine, this command will start a python 2 image with access to the current directory: `docker run --rm -it -v "$PWD:/app" python:2.7 bash` (IIRC, on my phone atm!) (Windows users will need to write `"/$PWD://app"` if using mingw/etc). Once inside, you can pip install, etc, and it'll all go away once you exit the terminal! If you want it to stick around, don't use --rm and add a --name to give it a name you can remember for later. It does require learning some docker, but it's a good investment :) I use the same technique to try out/play with other languages, versions, packages, etc. without making complicated mods to my actual computer. And there might even be docker images that come with certain packages/etc pre-installed for certain use cases! 2) Pycharm! A good python IDE, with virtualenv support baked in if you don't feel like playing around with a bunch of commands at all. Although disclaimer, I can't fully remember how hard it was to get things setup (or how easy it is to work with multiple python versions), so YMMV.
- RheingoldRiver 5y ago
  I don't think Pycharm will install different versions for you, but if you have multiple versions installed, it is indeed super easy to switch between them. Though if you have a ton of packages you'll have to reinstall them all for the right version, and if you're dealing with lots of venvs + system installs, you have to make sure to choose the right thing from the dropdown and you might get somewhat lost and confused if you don't know what you're doing. The right menu is File -> Settings -> Project: <your project name> -> Project Interpreter, and then you pick whatever you want by Python Interpreter. In Windows I use Chocolatey to manage Python versions, in Mac idk though.
  - rlayton2 5y ago
    It does install them too - however I have the pro version, and I'm not sure if that's a pro feature or not.
    - 5y ago
rcarmo 5y ago
This too is a solved problem. First of all, the bundled Python 3 in Big Sur is perfectly OK and works fine (it’s become my default after years of pyenv). Second, brew and pyenv “just work” if you need any other version. I’ve been developing in Python for decades, and it is one of the cleanest and easier approaches to running multiple runtimes I’ve used in any language.
BiteCode_dev 5y ago
Because python 2 has been unsupported for more than a year.

by warent 5y ago

blondin 5y ago

i sympathize. the problem is apple. they are (understandably) refusing to ship an up-to-date global python interpreter with macOS. not only that, they aren't removing the default 2.7 that they ship. macOS Big Sur ships Python 2.7. ha. ha. ha. none of the proposed "virtual environments" solutions are going to rescue you when you operate globally at the OS-level and not in a sandbox. been there.

wutbrodo 5y ago
> they are (understandably) refusing to ship an up-to-date global python interpreter with macOS What is the understandable reasoning?
- mbreese 5y ago
  It's pretty common to have kept `/usr/bin/python` as Python2. This is the most conservative option and won't break anything that's already running. Anyone who is using Python currently will have already installed Python 3 (or knows how to do this), and is probably using `#!/usr/bin/env python3`. As an OS vendor with many (many...) systems in the wild, you don't want to switch Python versions on people unexpectedly. Especially when it's still pretty painless to keep python2 around even if there is an installed python3. For anyone that's still using python2 (as a nearby comment mentioned), there is now at least a warning to avoid using the default Python 2.7 (/usr/bin/python). For an OS vendor, this transition takes a long time... but at least it's in process.
  - wutbrodo 5y ago
    Oh, sure, it's definitely not a good idea to change what the unqualified python binary refers to. But I interpreted "refusing to ship an up-to-date global python interpreter with macOS" as meaning that Python3 isn't shipped at all, with the binary name "python3"). Is that the case? If so, I still don't understand the reasoning.
    - mbreese 5y ago
      I don’t think anything in macOS (the base OS) requires Python, does it? If not, then, I don’t see why Apple would want to ship any Python with the OS. Let people install the Python version they want and then the users will have to maintain it.
      - wutbrodo 5y ago
        The comment I asked rhe question of said: > the problem is apple. they are (understandably) refusing to ship an up-to-date global python interpreter with macOS Ie the claim is that it's causing a problem for users. I don't have an opinion about this point, but it is the premise of my question.
JimDabell 5y ago
> not only that, they aren't removing the default 2.7 that they ship. Yes they are: $ python WARNING: Python 2.7 is not recommended. This version is included in macOS for compatibility with legacy software. Future versions of macOS will not include Python 2.7. Instead, it is recommended that you transition to using 'python3' from within Terminal. Python 2.7.16 (default, Aug 30 2021, 14:43:11) [GCC Apple LLVM 12.0.5 (clang-1205.0.19.59.6) [+internal-os, ptrauth-isa=deploy on darwin Type "help", "copyright", "credits" or "license" for more information. >>>
oefrha 5y ago
1. macOS ships a /usr/bin/python3 that is up-to-date at the time of the feature freeze of a major macOS release, e.g. macOS 11 ships Python 3.8.2 from February 2020. 2. /usr/bin/python being a symlink for python2.7 is entirely consistent with PEP 394 recommendations, especially the version before June 2019: https://raw.githubusercontent.com/python/peps/214736457f6d61a98c14915316056c2d1076cc3b/pep-0394.txt https://raw.githubusercontent.com/python/peps/214736457f6d61... * Unix-like software distributions (including systems like Mac OS X and Cygwin) should install the ``python2`` command into the default path whenever a version of the Python 2 interpreter is installed, and the same for ``python3`` and the Python 3 interpreter. * When invoked, ``python2`` should run some version of the Python 2 interpreter, and ``python3`` should run some version of the Python 3 interpreter. * If the ``python`` command is installed, it should invoke the same version of Python as the ``python2`` command (however, note that some distributions have already chosen to have ``python`` implement the ``python3`` command; see the `Rationale`_ and `Migration Notes`_ below). The 2019 update https://github.com/python/peps/commit/ae932bd6fd2c493d7d64ce328a5293bac4c48884 https://github.com/python/peps/commit/ae932bd6fd2c493d7d64ce... allowed more flexibility, but the old handling is still entirely okay.

ArchD 5y ago

No such problems on Linux, which is free and open-source. I think 'open-source' is the key.

Godel_unicode 5y ago
I think you mean you don't have such problems on Linux, there are plenty of people who trip over the fact that the default python on RHEL<= 7 was comically old and unintuitive to update... https://www.ibm.com/support/pages/work-around-frustrating-python-3-install-rhel7 https://www.ibm.com/support/pages/work-around-frustrating-py... https://unix.stackexchange.com/questions/468620/how-to-change-python-default-version-from-2-7-to-3-7-on-rhel-7 https://unix.stackexchange.com/questions/468620/how-to-chang...
- ArchD 5y ago
  You are comparing apples and oranges, obviously. Perhaps some people are just unconsciously too enamored with apples. OP's problem was not configuring default Python version as in your second link. Your first link is about some IBM stuff, and IBM is proprietary, so no comments there. Neither was OP's problem about setting up Python on an old version of the Mac OS. In any case, on old RHEL, you can just do something like this: https://www.2daygeek.com/install-python-3-on-centos-6/ https://www.2daygeek.com/install-python-3-on-centos-6/ Installing Python on Linux is much easier than you're trying to say. For the the love of apples.
  - Godel_unicode 5y ago
    Configuring the default python, also referred to as installing a new Python, is exactly what OP was doing. The process in the supplied link, which is the same as the process you weirdly called IBM proprietary even though it has nothing to do with IBM, is essentially the same as the process on MacOS. Realize that the OS python is not what you want, enable a non-default package repository with a few shell commands, install Python. Prejudice about anything to do with Apple aside, glad to see we agree that RHEL and MacOS have similar install processes.

NelsonMinar 5y ago

Using Python 2 is a big part of the problem. Modern Python 3 is a lot nicer. Also you're much better off if each Python project has its own virtual environment using the venv module.

deleted 5y ago
[deleted]
yjftsjthsd-h 5y ago
While I also quirked an eyebrow at the exact version, is 3 better at package management & environments?
- lacker 5y ago
  It's still a mess, honestly. They tried to standardize on venv but since it doesn't deal well with Python libraries that depend on non-Python components, conda is still better for many purposes.
  - anakaine 5y ago
    Except when Conda plays hard to get, like in any corporate environment with connection inspection, custom root CAs, or not quite admin privileges. Then Conda is an absolute dog and hard to work with, yet regular old python is fine.
  - isoprophlex 5y ago
    Can you give a specific example? I've had nothing but pain with conda in mixed linux/mac/win environment at work, and actively worked to get it deprecated. We're on plain venvs now, with the occasional setup.py Curious if I missed some useful case for it. - very slow dependency resolvers - using conda in docker is annoying - the worst thing: inconsistencies in downloading binaries and other resources between win/mac/linux when installing packages - conda insisting on messing with bashrc to run their 'activate' crap - beware the fool who runs 'sudo conda whatever' on a multiuser system

odonnellryan 5y ago

What are you trying to do? It generally is not a problem unless you are using old or obscure packages. Sure some projects need those things, probably a lot of them, but I don't think that is really pythons fault. Not that this couldn't be done better in python. What issues did you encounter?

NikolaeVarius 5y ago

I dont know how its actually possible to spend 4 hours getting lyton2 and pip setup at all. The issues deal with managing upgrades, not initial setup

i_like_apis 5y ago

4 hours? Yeesh. Here's how to do it in 5-10 minutes. Use pyenv to install any python version and pyenv-virtualenv to manage virutal environments. https://github.com/pyenv/pyenv https://github.com/pyenv/pyenv https://github.com/pyenv/pyenv-virtualenv https://github.com/pyenv/pyenv-virtualenv

nomel 5y ago
For me, pyenv on Mac is about 15 minute compile time with a bunch of environment variables required to make sure tkinter works properly.
- heavyset_go 5y ago
  brew install pyenv
- uranusjr 5y ago
  The compile time depends largely on dependencies. If you have OpenSSL, zlib, and whatnot pre-installed (either via Homebrew or self-compiled and specified with environment variables), the compile time is close to 5 minutes. If you don’t, by default pyenv (actually python-build) compiles all those from scratch, and can easily spend north of 20 minutes (mostly for OpenSSL).
- stonecharioteer 5y ago
  Use miniconda. It's much better.
  - nomel 5y ago
    The licensing is not compatible with my companies legal team.
rlayton2 5y ago
Anaconda is also great for beginners - GUI, lots of normal packages precompiled (also numpy, scipy, pandas, scikit-learn). If you do the full install, it comes with lots of packages pre-loaded.

jnwatson 5y ago

Please enough of this. Trying spending 2 minutes googling it. Hint: pyenv

alwillis 5y ago
Took the words out of my mouth. Let’s not over complicate things.
e3bc54b2 5y ago
virtualenv, pyenv, venv.. I'm sure they all work well, but for a newbie, the sheer choice is a killer, especially when they all work almost same, but not quite. Now compare that with cargo or npm and the canonical way makes newbie upbringing SL much easier.
DrOctagon 5y ago
I wanted to install python on a new Mac last night and just couldn’t get up and running. Closest I got was with using anaconda but although I could get the right env in the terminal I couldn’t get either paycharm or vscode to pick up the correct interpreter/packages etc. I’d almost guarantee there was something simple I was missing but for someone not familiar with the ecosystem getting python set up to do more than just hello world is a shitshow.
em500 5y ago
If you spend 2 minutes googling it (or even just reading HN comments here), you'll get various people recommending venv, pyenv, poetry, conda, pyflow and probably a whole bunch of deprecated stuff, where it's totally unclear to outsiders which one to use.
- NathanOsullivan 5y ago
  Fwiw if you are an outsider, having gone through this exact issue myself recently start with venv: https://docs.python.org/3/library/venv.html https://docs.python.org/3/library/venv.html It is a standard library module and serves as the base functionality, most the other things you list are third party tools that build on the venv concept in various ways. Once you grok venv, you will be in a position to understand if those tools can provide value to your particular situation.

guskel 5y ago

If you use pyenv, it shouldn't be that difficult.

fiddlerwoaroof 5y ago

Interesting, I don’t use Python much anymore, but my project setup was always something like: virtualenv -p interpreter venv source venv/bin/activate pip install . . . These days, I just use nix

shakna 5y ago
Replace the first line with python3 -m venv venv And you have the current state of things.

anothernerd2 5y ago

Install miniconda, it’s amazing. Takes roughly 30 seconds to install. After using conda I’ve never had environment issues

forgingahead 5y ago

Python dependency management is rubbish, and many python projects have incomplete or missing requirements.txt files. I dislike Python as well (why on earth is whitespace relevant??) but unfortunately if you want to tinker with any of the newest deep-learning projects, you'll need python. I use Anaconda for package management on Ubuntu, which helps a lot, but it's still not my preferred programming language.

saltyfamiliar 5y ago
> why on earth is whitespace relevant?? To eliminate the need for braces and semicolons, of course. It's part of what makes python so easy to read and write. Is it really such a problem? I honestly can't imagine disliking python. It's my goto for anything where performance doesn't matter due to its unmatched ergonomics and vast libs. Golang comes close but for some reason having to implement really common and basic things yourself is part of the language's design philosophy. Plus it's compiled so you can't just drop into the interpreter for a slick one-liner. What's your preferred quick and dirty scripting/programming langage?
- forgingahead 5y ago
  I prefer Ruby for quick scripting - in my opinion it beats Python in readability (sugarcoating handlers/hiding guts like not needing self littered everywhere), and seems to have more logical consistency in calls (eg: array.append(element) but len(array) in Python vs. array.append(element) and array.length in Ruby, amongst many other things). It's definitely a preference, and Python has a lot of library support that the Ruby community doesn't (yet, hopefully), but grandparent's comment about headaches setting up Python with a simple project are pretty common. Rarely do I encounter a Python project that "just works" - If your setup isn't exactly the same as the repo owner, and often even they don't even know why their setup is the way it is, then there's often a lot of fiddling and package adjustments needed. Not a deal breaker normally, but enough to make it more painful to quickly drop in and start experimenting with.

tus89 5y ago

Sounds more like the misfortune of using a Mac.

wenc 5y ago

I use the Anaconda distribution. I can create environments containing any version of Python, like this: conda create -n myEnv python=2.7 conda activate myEnv I think the problem is that unless someone already knew Python, they probably wouldn't understand environments, so their first thought would be to somehow install another version of Python and replace the system Python, or to use a switcher to switch between versions. That would be my first intuition too. (and I believe that's how Ruby works, via RVM). But Python works just a little bit differently in that it advocates for the use of its own environments to isolate dependencies. I'll have to admit it is not super intuitive (I already have a system package manager (apt, brew, etc.) and I have Docker containers -- why do I need another yet another environment?) but over time I've just accepted it for what it is. It's a Python convention.

lacker 5y ago
I mean, conda is installing another version of Python, and it provides a switcher to switch between environments. Conda and rvm are very similar to use.

lmm 5y ago

1. Python has a low barrier to entry and is a popular first language, so most users don't realise how bad it is. 2. Python was originally popular with old-school sysadmins, Debian types, and a lot of its package management is based around that philosophy of carefully hand-tended servers shared by multiple users.

iamcreasy 5y ago
Care to elaborate on what is bad? How bad are they compared to other languages? (Assuming you are always accepting some tradeoffs when moving from one eco system to another)
- sergiomattei 5y ago
  It's painfully archaic compared to languages that have all this sorted out. Pip is a recipe for disaster, indicated by the huge amount of churn in the Python packaging sphere. It's constantly the worst part of my day whenever I pick a Python project up. Conflicting dependencies, non-deterministic installs, etc. I used to cope with this crap fest until I tried Elixir and experienced the beauty of modern package management and build tools. One tool, Mix, that handles task running and dependency management with a proper resolver. I honestly think even Node has a better package management and tooling story. Also: virtual environments are a hack and a pain. Python is moving forward in this aspect with the recent PEP for the pypackages folder, but we're still a long way from adoption. All of this stuff is painful for beginners. Virtual environments might seem easy to us, but I've had ridiculous amounts of trouble explaining why they're necessary to beginner developers. Then you have to explain `poetry` or `pip freeze`. Even I have trouble coming back to older projects of mine and I'm an experienced Pythonista: I usually waste an hour or two trying to sort the pip dependencies out with whatever conflicts the resolver comes up with this time. Python package management is not okay, we're all just used to coping with it. Other languages put it to shame.
  - cerved 5y ago
    Package management is pretty fubar for in every language I've tried but python is one of the worst

deleted 5y ago

[deleted]

cdrini 5y ago

Folks have given a number of good options here, but I thought I'd mention some other ones in case they're helpful for your use case. 1) docker! If you only plan on tinkering with something and don't want to install a bunch of random things on your machine, this command will start a python 2 image with access to the current directory: `docker run --rm -it -v "$PWD:/app" python:2.7 bash` (IIRC, on my phone atm!) (Windows users will need to write `"/$PWD://app"` if using mingw/etc). Once inside, you can pip install, etc, and it'll all go away once you exit the terminal! If you want it to stick around, don't use --rm and add a --name to give it a name you can remember for later. It does require learning some docker, but it's a good investment :) I use the same technique to try out/play with other languages, versions, packages, etc. without making complicated mods to my actual computer. And there might even be docker images that come with certain packages/etc pre-installed for certain use cases! 2) Pycharm! A good python IDE, with virtualenv support baked in if you don't feel like playing around with a bunch of commands at all. Although disclaimer, I can't fully remember how hard it was to get things setup (or how easy it is to work with multiple python versions), so YMMV.

RheingoldRiver 5y ago
I don't think Pycharm will install different versions for you, but if you have multiple versions installed, it is indeed super easy to switch between them. Though if you have a ton of packages you'll have to reinstall them all for the right version, and if you're dealing with lots of venvs + system installs, you have to make sure to choose the right thing from the dropdown and you might get somewhat lost and confused if you don't know what you're doing. The right menu is File -> Settings -> Project: <your project name> -> Project Interpreter, and then you pick whatever you want by Python Interpreter. In Windows I use Chocolatey to manage Python versions, in Mac idk though.
- rlayton2 5y ago
  It does install them too - however I have the pro version, and I'm not sure if that's a pro feature or not.
  - 5y ago

rcarmo 5y ago

This too is a solved problem. First of all, the bundled Python 3 in Big Sur is perfectly OK and works fine (it’s become my default after years of pyenv). Second, brew and pyenv “just work” if you need any other version. I’ve been developing in Python for decades, and it is one of the cleanest and easier approaches to running multiple runtimes I’ve used in any language.

BiteCode_dev 5y ago

Because python 2 has been unsupported for more than a year.