(This is because the directory containing python.exe hasn't been added to the PATH environment variable.)
And similar issues.
As we know, versions of Python supported by the currently WIP version of Django [1]will be 3.5 or newer.
Also,
since version 3.3, the official Windows Python installer [2]includes an
implementation of the 'Windows python launcher' proposed by [3]PEP 397.
This tool gets installed to a system directory always present in PATH
and can act a a pivot to get scripts like django-admin.py, manage.py and runtests.py executed by the right Python interpreter binary, even when
running inside a virtual environment.
This led me to think it would be possible to simplify lives of our Windows users because today, with a default installation of Python 3.5 o 3.6 (tested this with Python 3.5 on a Windows 7 system) Windows users can simply write
django-admin.py startproject foo
And things Just work (TM). be it either using the global interpreter, or using a virtual enviromnent.
The PR also modifies the introductory document for contributors to Django so it stops suggesting Windows users to use the alien Git Bash shell. At first is seems like a good idea but considering facts like
- It forces users to type in "Unixisms" like `./manage.py` or `mkdir ~/.virtualenvs`
- Is incompatible with venv (another useful tool, also new in Python 3.3 as part of the standard library) and forces the document to divert Windows users so they install and use virtualenv, putting them in the strange situation of having to do that because then they can activate the virtual env by using the Unix shell-specific `source` builtin instead of using native scripts activate.bat or activate.ps1
Another change proposed by the PR is the addition of a custom Sphinx directive that modifies the UI of CLI example text boxes so they can show a native prompt and native command line input as it should actually be typed by the user either on Unix-based shells or the Windows command prompt through a tabbed interface.
Feedback is welcome.