Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Escaping from Anaconda's Stranglehold on macOS

paulromer.net

Post reply on HN
Print view View original

271–280 of 286 posts

Re: Escaping from Anaconda's Stranglehold on macOS

#271

Post by swiftcoder »

promer wrote: post #262
swiftcoder wrote: post #202

Earlier quoted context omitted.

> On macOS, there hasn't been a system Python since 12.3 came out in Jan of 2022 It may not be pre-installed, but if you install Xcode it will also install python3 in /usr/bin/ for you...

The assertion that seemed incorrect was that I was recommending an option that would install libraries to the system Python. Xcode does put a binary with the name python3 into `/usr/bin`. This is not a system Python, but set that aside. Can you explain how someone might pip install libraries to this instance of Python?

Once Xcode's python is installed, `pip3 install ...` will install libraries to that python installation (assuming you haven't aliased pip3 to another installation, as it appears the anaconda installer did)

Re: Escaping from Anaconda's Stranglehold on macOS

#272

Post by promer »

swiftcoder wrote: post #271
promer wrote: post #262

Earlier quoted context omitted.

The assertion that seemed incorrect was that I was recommending an option that would install libraries to the system Python. Xcode does put a binary with the name python3 into `/usr/bin`. This is not a system Python, but set that aside. Can you explain how someone might pip install libraries to this instance of Python?

Once Xcode's python is installed, `pip3 install ...` will install libraries to that python installation (assuming you haven't aliased pip3 to another installation, as it appears the anaconda installer did)

The install by xcode of a python3 binary in `/usr/bin` does not come with its own copy of pip3.

So either your command will fail to install or it will use a version of pip that is on PATH but was installed by some other version of python. So in either case you can't install a library into what you are mistakenly calling a system python.

So the original assertion was not true and you have not been able to make up an ex post justification for it.

Re: Escaping from Anaconda's Stranglehold on macOS

#273

Post by moi2388 »

cuddlyogre wrote: post #233
moi2388 wrote: post #180

Earlier quoted context omitted.

How in the world is c# too complicated? Console app, top level statements, vs code. As easy as Python. Easier because your env isn’t messed up. If they can’t manage that they have no business doing data science or something similar to begin with

You sound like you have been doing this for way too long to know what it takes to teach beginners.

Not at all. I still teach interns and until 2 years ago complete beginners.

I can teach them a console app with top level statements and have it running before they have installed a Python virtual environment.

Re: Escaping from Anaconda's Stranglehold on macOS

#274

Post by swiftcoder »

promer wrote: post #272
swiftcoder wrote: post #271

Earlier quoted context omitted.

Once Xcode's python is installed, `pip3 install ...` will install libraries to that python installation (assuming you haven't aliased pip3 to another installation, as it appears the anaconda installer did)

The install by xcode of a python3 binary in `/usr/bin` does not come with its own copy of pip3. So either your command will fail to install or it will use a version of pip that is on PATH but was installed by some other version of python. So in either case you can't install a library into what you are mistakenly calling a system python. So the original assertion was not true and you have not been able to make up an e…

I have a `/usr/bin/pip3`, and it appears to have been installed at the same time as the rest of XCode. Not sure what's up with your install:

  % ls -la /usr/bin/(pip3|python3|clang)
  -rwxr-xr-x  77 root  wheel  119008  4 Aug 12:31 /usr/bin/clang
  -rwxr-xr-x  77 root  wheel  119008  4 Aug 12:31 /usr/bin/pip3
  -rwxr-xr-x  77 root  wheel  119008  4 Aug 12:31 /usr/bin/python3

Re: Escaping from Anaconda's Stranglehold on macOS

#275

Post by promer »

swiftcoder wrote: post #274
promer wrote: post #272

Earlier quoted context omitted.

The install by xcode of a python3 binary in `/usr/bin` does not come with its own copy of pip3. So either your command will fail to install or it will use a version of pip that is on PATH but was installed by some other version of python. So in either case you can't install a library into what you are mistakenly calling a system python. So the original assertion was not true and you have not been able to make up an e…

I have a `/usr/bin/pip3`, and it appears to have been installed at the same time as the rest of XCode. Not sure what's up with your install: % ls -la /usr/bin/(pip3|python3|clang) -rwxr-xr-x 77 root wheel 119008 4 Aug 12:31 /usr/bin/clang -rwxr-xr-x 77 root wheel 119008 4 Aug 12:31 /usr/bin/pip3 -rwxr-xr-x 77 root wheel 119008 4 Aug 12:31 /usr/bin/python3

Yes, you are correct. pip3 is installed by XCode.

I was having trouble understanding the scenario you seem to have in mind because it never occurred to me that someone would try to run Python without doing an install from python.org as I explicitly recommend.

If someone does install a version of Python from python.org, it puts the bin folder for that version first on PATH via this line in .zprofile:

PATH="/Library/Frameworks/Python.framework/Versions/3.11/bin:${PATH}"

It also puts a symlink for python3 and pip3 into the `/usr/local/bin` folder that comes ahead of `/usr/bin`.

So if the user runs

`pip3 install ...`

it will not find the version in `/usr/bin` because there will be two other directories ahead of it on the path that have an instance of `pip3`.

As an aside, if they do the improbable and run something like

`/usr/bin/pip3 install ...`

or if they do not have any Python from python.org installed and run

`pip3 install`

what they will end up with is a user-install that puts libraries under their `~/Library` directory because (at least on an Apple Silicon mac) pip can't write to `/usr/bin`. This fallback to a user-install is confusing to people who encounter it, but it is very different from "installing to the system python."

To summarize, it is exceedingly unlikely that a student who is not comfortable running commands from the terminal is going make the mistake you seem to be worried about and end up with libraries in the user-install location:

1. They do not install an official Python even though that is exactly what I recommend.

2. They do install XCode or XCode Command Line tools, then try to use `pip3 install ...`

Re: Escaping from Anaconda's Stranglehold on macOS

#276

Post by m0llusk »

eru wrote: post #134
orlp wrote: post #102

Earlier quoted context omitted.

What I do on every dev machine is build Python from source and install it to ~/.localpython and put it in my path. Then I can pip install away care-free, and quickly run scripts / repls without having to activate an environment.

Why does it need to be built from source for that?

Typically building from source is done to include optional components such as with the ./configure --with-pydebug option. With many projects make doc is an option because so many prefer to skip that part of the build in favor of online documentation.

Re: Escaping from Anaconda's Stranglehold on macOS

#277

Post by sunshowers »

pwang wrote: post #222
sunshowers wrote: post #19

Earlier quoted context omitted.

> use by individual hobbyists, students, universities, non-profit organizations, or businesses with less than 200 employees is allowed, and all other usage is considered commercial and thus requires a business relationship with Anaconda Wow this is so deliberately ambiguous about universities with more than 200 employees. Shameful.

I posted an update about this: https://www.linkedin.com/posts/pzwang_hi-everyone-recently-t... TLDR - we are working to clean up this language to leave it clear that educational institutions are exempt, and that these commercial terms do not apply to third-party channels hosted at anaconda.org (which includes conda-forge).

Thank you. I do hope you reflect on how ambiguous the language was allowed to be for years.

Re: Escaping from Anaconda's Stranglehold on macOS

#278

Post by brewmarche »

promer wrote: post #263
brewmarche wrote: post #15

You can just keep Anaconda and just use it as a pyenv replacement, e.g.: conda create -n "myenv" python=3.8 conda activate myenv Then just use pip in your environment, if you don’t like conda packages. Not sure what the paragraph about being able to install multiple Python versions after getting rid of Anaconda is about.

> Not sure what the paragraph about being able to install multiple Python versions after getting rid of Anaconda is about. The sentence says "install and run". The problem is with "run." On macOS, most students who install Anaconda accept the default, which is to autoactivate the base conda environment every time someone starts a terminal session. As a result, the instructions for starting an official Python don't wo…

I did not know that (only know it from Windows), thanks for the explanation.

It looks like

  conda config --set auto_activate_base false
would be another fix for that. Or adjusting .condarc manually if you insist on not using the CLI. However I think teaching students about (virtual) environments will require them to know at least some CLI basics anyway.

Re: Escaping from Anaconda's Stranglehold on macOS

#279

Post by bmitc »

regularfry wrote: post #253
bmitc wrote: post #243

Earlier quoted context omitted.

There really is more than one particular face of poor design in Python. I honestly remain confused why people use and love Python so much. It very much says something.

Oh, there are many . There are just comparatively few that you can point at as being quite as directly responsible for dev misery as thé packaging system.

Lol. I see where you're coming from.

Re: Escaping from Anaconda's Stranglehold on macOS

#280

Post by promer »

brewmarche wrote: post #278
promer wrote: post #263

Earlier quoted context omitted.

> Not sure what the paragraph about being able to install multiple Python versions after getting rid of Anaconda is about. The sentence says "install and run". The problem is with "run." On macOS, most students who install Anaconda accept the default, which is to autoactivate the base conda environment every time someone starts a terminal session. As a result, the instructions for starting an official Python don't wo…

I did not know that (only know it from Windows), thanks for the explanation. It looks like conda config --set auto_activate_base false would be another fix for that. Or adjusting .condarc manually if you insist on not using the CLI. However I think teaching students about (virtual) environments will require them to know at least some CLI basics anyway.

Yes, this would be another way to escape from the conda base environment.

And as I've indicated in other responses, I absolutely agree that students need to learn how to edit files and run commands from the terminal. The only question concerns the order in which to teach these basics.

But please understand the facts. The majority of students I've encounter who have Anaconda installed on a Mac, had totally given up on the possibility of running an official version of Python. This, by the way, is a big indictment of the Anaconda Navigator, which encourages students to keep using a GUI instead of mastering files and shell commands.

Part of why I recommend the basics:

- an official python - pip and pypi.org - venv from the standard library

is that it gets them out of this pattern of this dependency on a GUI. This, by the way, also gives me some hesitation about VS Code. It too reinforces the GUI as the way to set up a working environment.

Post reply on HN