Fortunately I’ve been on Windows today so I’ve had a little look into it. The following is my rather lengthy interpretation thought I can’t promise it’s 100% correct.
site-packages\ is the standard location for the installs of third party modules/packages (this is where things like numpy and jupyter are added).
In this instance you have two different sets of site-packages, “system” and “user” site-packages.
When you first installed Python it likely would’ve included a few basic things in the “system” site-packages (intsalls of
setuptools etc.). By using
pip install package you install new packages to your “system” site-packages (for you it seems to be something like
The process of installation sometimes adds scripts to the neighbouring
Scripts\ directory (there would be different
Scripts\ directories for “user” and “system” site-packages). Not every module adds such scripts but certain packages such as
jupyter notebook do. In this instance your PATH variable probably contains something like
C:\\Users\\username\\AppData\\Local\\Python\\Python39\\Scripts as one of the entries (this is the “system” site-packages path for you). If you had a look in this directory you’d find stuff like
pip.exe and similar.
By having this directory on your PATH you can run certain scripts it contains like
pip without using the full path to run it e.g.
pip instead of the full
This next bit may not be entirely accurate. I try to avoid user site-packages for the most part and work in isolated environments or containers so I only tested this quickly.
If I’m not mistaken there would be a second site-packages designed for individual users located somewhere in
...\AppData\Roaming\. Installing packages here normally requires the
--user flag when using pip (or a fallback if certain admin controls prevent alteration of “system” site-packages). So
pip install --user numpy for example. This set of site packages does not appear to be on your PATH by default (which might be intentional). So you cannot simply use items from the
\Scripts directory of your “user” site-packages like you can from the “system” site-packages.
python command is already on your PATH in this case so you can use it directly. It (python) has its own path for finding python packages. You can see what it tries to read from with
python -m site.
If you run that command you’ll likely see
sys.path includes what we called the “system” site-packages AND at the very end there will be some additional flags mentioning
USER-SITE with a path and whether or not it is being used (it is probably set to True). If it is set to
True (and has the correct path) then python can find and use your “user” site-packages.
When you use
python -m name it attempts to run a module as a script which in this case is exactly what we want. So we can run
jupyer notebook as a script via Python,
python -m jupyter notebook skipping PATH entirely (except to run
python itself here ).
Conda might be a little nicer but it’s not overly different. It provides a lot of things at once and is probably a little easier to get started with (it does its best to stay off your PATH variable and only initlialises itself in certian interactive terminals). You might have an easier time with it; long-term you’d still want to use virtual evnironments regardless.