> 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 work.
If you use Anaconda on Windows, you will not be able to test the effects of autoactivate.
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.
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.
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:
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 ...`
This is a suggestion that deserves serious consideration. I started using VS Code after I had learned all the basics so I don't know what it feels like to be a new learner who is getting started by using VS Code. But it sounds like it worked for you. (And on campus, the proxy should not be an issue.)
It does answer the question of which text editor to use when the time comes to teach them about editing text files. For a course, it helps that it is free and available on both macOS and Windows.
I have a vague recollection that at some point I was testing without an install of Python and after I selected the Python extension for VS Code, it offered to install one for me. (I don't recall if this was on macOS or Windows and memory could be playing a trick on me.) But in any case, the people behind VS Code do seem to be trying very hard to make it easy for someone who is getting started.
I am a little uneasy about the nudges to use Copilot, but on balance, it might offer a better path for students who are getting started.
FYI, I offered a comment above that might clarify. There are two questions:
1) How can we get a specific group of students who feel helpless started on the path to learning?
2) What should we teach students?
In the post linked here, I tried to be clear that these are instructions for a very specific group of students who are stuck and don't know what to do. I agree that they are not the right instructions to offer to the typical reader of this site.
The comment and the second post that it references address what we should teach.
Thanks for making this point. People who work on Windows may not realize how aggressive and disruptive Anaconda is on macOS. If you open a terminal and run the `lipo` command that macOS gives you to get information about a file, you will be running a version of that command that Anaconda installed, not the one that Apple manages and updates. And `lipo` is just one of many such examples.
Based on limited testing on Windows, Anaconda does not seem to do anything comparable on that OS.
I appreciate all the comments. I agree with most, even when they disagree with me or each other. I especially agree with the questions several people raise: What it is that we should teach? In which order?
I think there is a consensus about what a student should end up knowing. Even if they are not going to become developers, they should be able to edit text files; they should be able to run commands from the terminal; they should understand PATH. They should create a virtual environment every time they start a new project.
Where we might disagree is how to get them to the point where they know all those things.
I offered to write this post for a colleague who is now facing the issue I faced when I taught last spring. My only goal was to help the students who can't get started running Python from python.org. When I say that they don't know what an editor is or how to use the command line, I just taking those as the facts on the ground. What I didn't say (at least not very clearly) is that they need to learn these other things. I did hint in the end that some of these probably need to come before learning to use a virtual environment. I know this is controversial.
Because the first post was narrowly focused, I wrote a subsequent blog post called "Environment as Code" that is more specific about the goal and offers a specific sequence to follow to get there.
If you have any reactions, I'd be interested to hear them. In a deep sense, I think that the issue here is how to free students from the GUI. If we can do this, it will change how they interact with the computer for the rest of their lives. If there is a better way, I'll be happy to support it.
I agree with most of your "Environment as Code" post. Virtual environments are overhyped and even experienced developers frequently have to fix their venv or repair their conda install. You get to depend on a tool that's not necessary and distracts from the original purpose of using the software.
On Unix, it is even trivial to have parallel installations.
Build two pythons:
./configure --prefix=/home/foo/a && make && make install
make distclean
./configure --prefix=/home/foo/b && make && make install
Install packages:
/home/foo/a/bin/python -m pip install bar
/home/foo/b/bin/python -m pip install quux
This is completely isolated. You can do the same by using the Windows installer to install to different directories. If an installation breaks, remove it and reinstall.
My experience is that people who recommend various environment software often like strict bureaucratic procedures, or have a financial interest in pushing the software or are simply not experienced and do what they are told.
I agree. It would be better if people understood the costs and benefits of virtual environments and used costs and benefits to guide decisions about how and when to use them.
The general observation I would add is that these change with the level of experience of the person writing the code. I found it helpful and harmless to avoid them when I was experimenting. Now, I use them automatically.
I know that it made people angry, but I think it was reasonable to say that if someone does not know how to edit a file and is not comfortable using the terminal, they are not ready for virtual environments.
Re separation, another option is the one I recommend in the
"Environment as Code" post: Right now, I'd suggest installing
- Python3.12
- Python3.11
- Python3.10
Then use edits to `.zprofile` to specify which will be used in any terminal session. It does require the use of an editor to make changes to `.zprofile`, which is where the official versions put the lines that add things to the user PATH. I think it is very helpful to get people familiar with how profiles set PATH for any terminal session and how easy it is to control by commenting out or commenting back in lines in `.zprofile`.
If they are unable to use a shell, don't understand environments etc. I would push them onto some specific IDE/plugin combination that creates a new virtualenv, handles PATH etc. for every new project.
Dealing with environments and understanding how different parts of the filesystem relate to each other is its own pretty steep learning curve. You wouldn't want them to get tripped up on that while they are learning to program, so I think I would opt to teach the two as entirely different concepts and not mix them at first.
No idea if an appropriate IDE/plugin combination exists! Surely there is one.
One suggestion that someone endorsed in another comment is to use VS Code. This would not be my preferred choice, but it would be useful to run an experiment in which students who are new to code start by installing it and following its suggestions about how to configure a working environment. One advantage with this approach is that it introduces students to a text editor.
A second alternative is the Idle environment that is included with every official install of Python from python.org. I have not used it much and I've never tried to teach a course with it. But it comes from the most trustworthy source in this complicated environment.
I'd be very interested in hearing about experience using these to start learning from the very beginning or using them to teach a course for people who are just getting started.
> Although one can install a plain-vanilla Python and all required libraries by hand, we recommend installing Anaconda ...
In a novice course, if the official version of Python and its tools all work, why is this organization recommending a product from a for-profit organization that requires acceptance of some complex and potentially costly provisions in its terms of use?
As much as I would rather not associate with these people (to stay polite), especially in an educational context, note that you do see people recommending the use of VSCode / Github / Windows / MacOS here all the time, all of which are orders of magnitude worse than Anaconda.
Have any downvoters actually even read Ayn Rand, or is it the usual people who don't even have to, because they know all they need to about her?
This segment, with it's hyperbole, ridiculous black and white simplification of complex matters, and tone of (over)confidence is unmistakably typical of her writing style:
"Jupyter rewards transparency; Mathematica rationalizes secrecy. Jupyter encourages individual integrity; Mathematica lets individuals hide behind corporate evasion. Jupyter exemplifies the social systems that emerged from the Scientific Revolution and the Enlightenment, systems that make it possible for people to cooperate by committing to objective truth; Mathematica exemplifies the horde of new Vandals whose pursuit of private gain threatens a far greater pubic loss–the collapse of social systems that took centuries to build.
Membership in an open source community is like membership in the community of science. There is a straightforward process for finding a true answer to any question. People disagree in public conversations. They must explain clearly and listen to those who response with equal clarity. Members of the community pay more attention to those who have been right in the past, and to those who enhance their reputation for integrity by admitting in public when they are wrong. They shun those who mislead. There is no court of final appeal. The only recourse is to the facts.
It’s a messy process but it works, the only one in all of human history that ever has. No other has ever achieved consensus at scale without recourse to coercion."
You are correct that the post misused the terms major version and minor version.
I'll fix it, and note the error and your catch, because
- I don't want to spread misinformation; and
- the right thing to do is to acknowledge the contributions that others make.