[promer]

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.

[hwgern]

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.

[promer]

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

Later, one can introduce them to `.zshrc`.

[bardan]

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.

[promer]

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.

[fergie]

Are you familiar with Software Carpentry? If so, what do you think about it? -> https://www.ub.uio.no/english/libraries/dsc/carpentry-uio/

[promer]

If you visit the link https://swcarpentry.github.io/python-novice-inflammation/ which offers the introduction to Python, you'll find this strange statement.

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