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.
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 ...`
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.
> 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?
> 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.
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.
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`.
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.
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.