Change needed for pip - Django installation documentation

First, my apologies. Terminology is hard, and often not suited to casual discussion; and it seems this led me to misjudge your experience greatly. (Reading tone is also hard; for what it’s worth I only intended to be matter-of-fact, and likewise I didn’t perceive any particular annoyance from you.)

Adding Python to the PATH variable manually in DOS certainly resolves the issue. However, in the OP you mentioned that “Windows GUI did not let me” modify the path, which is noteworthy. I can’t think of any reason why that would ever fail, done properly; but there is a common oversight people make when trying to use the GUI for this - it doesn’t affect already-open terminal windows:

(The same can happen with the installer, but people usually don’t notice because they wouldn’t have a terminal window already open while running the installer.)

As for the installer itself, nowadays (and for many years) Windows developers have been more or less expected to create installers if there are any meaningful setup steps (i.e. any reason why the program can’t just be dropped in some arbitrary place and double-clicked to execute). It’s generally expected that setup can also be modified by using the OS-level “Programs and Features” UI, which will re-run the installer (I’m not clear on whether it passes a special flag to the installer program or just what). To my understanding, this is supposed to work for the Python installer, including for the PATH setting - i.e., you can “modify” the installation, check or un-check the box, and PATH should be re-adjusted as appropriate. But aside from some general conventions, every application developer is on their own to design the installer - because every program has potentially unique requirements for setup.

I agree that the option should be more prominent, and given some appropriate discussion, because it’s unusual for installers to do this. Almost everything installed on Windows will happily add itself to PATH if it deems that necessary (for example, because multiple executables are installed that need to communicate by script) without considering any potential consequences. After all, ordinary programs are meant for ordinary users - who may never open a CMD window unless being directly hand-held through the process by a support technician.

My best guess is that the goal was to avoid intimidating those exact users - since Python is certainly perfectly usable by only ever installing a single version, only ever editing the scripts in IDLE (opened by double-clicking a Desktop shortcut), and perhaps running the scripts by double-clicking them (which depends on a file association in the Registry, not on the PATH setting). However, we do get a lot of questions related to the PATH setting here - including the issue you describe. But programmers in the long run need to understand how PATH works, as part of understanding how file paths work - along with relative vs. absolute paths, etc. (As computers - and now cell phones - become more “user friendly”, people have been losing that knowledge; so nowadays, new programmers may ask questions that even ordinary computer users would have been able to answer many years ago.)

I also agree that there should be some explanation written there - but I can’t really think of exactly what it should say. Hyperlinking to the “Using Python on WIndows” documentation would be a good start, at least.

But there are good reasons why the PATH modification is opt-in - here’s some previous discussion from late 2020, for example:

The core underlying issue is that Windows wants each application to have a separate subfolder within Program Files for the .exe along with any support files that are particular to that program (for Python, that would include things like the standard library source code). So, each new application needs a new PATH entry in order to be found that way. On UNIX-like systems, the actual executable applications are normally side-by-side in /usr/bin (or /usr/local/bin etc.), while any supporting, non-executable files are in a subfolder of /usr/lib (or /usr/local/lib etc.). With that setup, running python (or python3, python3.12 etc.) doesn’t require separate PATH entries - because they all use the same one, which is already there by default.