Wonderful piece. Thanks for the effort.

I am probably representative of one or more of the types of people you have encountered in your training career. I started teaching myself Python a couple of years ago, after a long time away from programming, after a long-ago Fortran, sh, and C programming career.

Somehow, through a combination of luck, crusty old wisdom, and a personal mindset that says, "First learn how to do long division, by hand, before you reach for the calculator," I ended up coming to your exact conclusion: "So python.org, “-m”, pip and venv? Yeah."

If you're interested, here's how.

I run mostly on Windows, so the first part seemed obvious: downloading the installer from python.org felt canonical, so why not try that first? And ... it just worked. Doing a minor version upgrade (3.<something>.N to 3.<something>.N+1)? It just worked. Doing a major version upgrade (3..N to 3..N+1)? It just worked. And hey, look at that! The minor version stay in the same 3.<something> directory (folder), but the major versions started a fresh one! That's just how I'd do it! ;)

The `py` command that came along with the initial installation was appealing right off the bat because it meant typing four or five few characters. Only later did I realize what else it provided. For example: "Really? All you need to do to run an earlier version of Python is `py -3.<N-1>` instead of `py`? That's it??? Wow! Nice!"

Re: -m. I might have had a minor problem once or twice running `pip` instead of `py -m pip`, but the question really got settled one day, a year or so ago, by reading a Brett Cannon post. I don't remember the details of his argument, just that it convinced me at the time, and hey, it's Brett Cannon. So, another non-issue, ever since.

Re: pip. I tried a few of the alternatives to pip back when I was first starting out, in part because "look! shiny!" and in larger part because of the very sort of advice you are critiquing in your post. Results: (1) I couldn't wait to get Anaconda off my machine within the first hour, let's just say that. (2) I gave poetry a few days, and kept trying to get along with it, but I ended up concluding that it was like so many other programs that I have always disliked, for this reason: "Stop trying to do what you think I should do. Stop trying to help me behind my back."

As an aside, this is why I have yet to try VS Code, much less WSL. A couple of Cygwin terminal windows and Emacs? Good to go. At least for now.

Finally, venv. Back in the very beginning, I kind of hated it. I knew that everyone preached that The Only Way to try out a new-to-me 3rd party package was by firing up a venv before doing any `py -m pip` installing. But it just felt like unnecessary friction, it took a while to realize what was going on with other imports suddenly not working, and I finally thought, "`py -m pip uninstall` works so well ... okay, I'm just going to be a bad person and not used venv." Here, I had the advantage of being in a Windows environment, as opposed to Linux or Mac, so that I didn't have to worry about fouling up the system's preinstalled Python.

I have come around on that last bit since. Initially, because I discovered some packages quietly downgrade other packages as part of their installation. That was not fun! Later on, I got to the point where I felt confident enough to try things like forking other people's repos so that I could try adding a feature, so, obviously (to people who have gained enough experience), there's no substitute for a venv in that case.

I am just starting out on the whole packaging aspect. The initial motivation was wanting to bundle up some of my own code so I wouldn't have the constant nuisance and mess of mixing in sys.path.insert() and sys.path.append() all over the place. And I'm now at the point where I just put together my first pull request, so packaging became a hard requirement. As with everything above, my instinct has been to go with the simplest possible approach to start. Basically, `py -m pip install -e .` and pyproject.toml. I figure that if I get to the point of doing so much packaging that some aspects of the bare-bones approach are starting to feel tedious, then, sure, I'll likely take another look at some of the other things that the pros recommend.

But until then, the basic tools make me feel, just as you say, like I can focus on what I want: learning Python, instead of fighting with tooling.

Thanks again.