We Keep Coding

Prevent a Python-embedded to look in my default path C:\Python38 for modules

I'm using Cython in --embed mode to produce a .exe. I'm evaluating the Minimal set of files required to distribute an embed-Cython-compiled code and make it work on any machine. To do this, I only copy a minimal number of files from the Python Windows embeddable package.
In order to check this, I need to be sure that the current process I'm testing doesn't in fact use my system default Python install, i.e. C:\Python38.
To do this, I open a new cmd.exe and do set PATH= which temporarily removes everything from the PATH. Then I can test any self-compiled app.exe and make sure it doesn't reuse C:\Python38's files under the hood.
It works, except for the modules. Even after doing set PATH=, my code app.py
import json
print(json.dumps({"a":"b"}))
when Cython---embed-compiled into a .exe works, but it still uses C:\Python38\Lib\json\__init__.py! I know this for sure, because if I temporarily remove this file, my .exe now fails, because it cannot find the json module.
How to completely remove any link to C:\Python38 when debugging a Python program which shouldn't use these files?
Why isn't set PATH= enough? Which other environment variable does it use for modules? I checked all my system variables and I think I don't find any which seems related to Python.

Python has a quite complicated heuristic for finding its "installation" (see for example this SO-question or this description), so probably it doesn't find the installation you are providing but the "default" installation.
Probably the most simple way is to set the environment variable PYTHONPATH pointing to the desired installation prior to start of the embedded interpreter.
By examination of sys.path one can check whether the correct installation was found.

Thanks to #ead's answer and his link getpath.c finally redirecting to getpathp.c in the case of Windows, we can learn that the rule for building the path for module etc. is:
current directory first
PYTHONPATH env. variable
registry key HKEY_LOCAL_MACHINE\SOFTWARE\Python or the same in HKCU
PYTHONHOME env. variable
finally:
Iff - we can not locate the Python Home, have not had a PYTHONPATH
specified, and can't locate any Registry entries (ie, we have nothing
we can assume is a good path), a default path with relative entries is
used (eg. .\Lib;.\DLLs, etc)
Conclusion: in order to debug an embedded version of Python, without interfering with the default system install (C:\Python38 in my case), I finally solved it by temporarily renaming the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Python to HKEY_LOCAL_MACHINE\SOFTWARE\PythonOld.
Side note: I'm not sure I will ever revert this registry key back to normal: my normal Python install shouldn't need it anyway to find its path, since when I run python.exe from anywhere (it is in the PATH for everyday use), it will automatically look in .\Lib\ and .\DLL\ which is correct. I don't see a single use case in which my normal install python.exe wouldn't find its subdir .\Lib\ or .\DLL\ and requiring the registry for this. In which use case would the registry be necessary? if python.exe is started then its path has been found, and it can take its .\Lib subfolder, without help from registry. I think 99,99% of the time this registry feature is doing more harm than good, preventing a Python install to be really "portable" (i.e. that we can move from one folder to another).
Notes:
To be 100% sure, I also did this in command line, but I don't think it's necessary:
set PATH=
set PYTHONPATH=
set PYTHONHOME=
Might be helpful to do debugging of an embedded Python: import ctypes. If you haven't _ctypes.pyd and libffi-7.dll in your embedded install folder, it should fail. If it doesn't, this means it looks somewhere else (probably in your default system-wide Python install).

How to access my custom python scripts from CLI in order for them to act on any file?

I am having difficulty accessing my custom scripts from the command line (python3 unzipit.py "C:\Users\Me\downloads\zipfilehome"). I want to have my scripts act on any file, no matter where they are. I don't want to have the script file in the same directory in order for it to work. I followed this question's top answer to no avail. Note: I am using Windows 10 and all my python versions are in the path with no issues accessing them.
What I did (I always refresh my CLI with every change)
In the system environmental variables:
Path: (unchanged since installation) C:\Path2Python27;C:\Path2Python27\scripts;C:\Path2Python37;C:\Path2Python37\scripts;
PYTHONPATH: C:\Path2Python37;C:\Path2Python37\scripts;C:\Users\Me\myscripts\py
Things I also tried
system environmental variables
Path: C:\Path2Python27;C:\Path2Python27\scripts;C:\Path2Python37;C:\Path2Python37\scripts;C:\Users\Me\myscripts\py
moving the same stuff to user env's Path
moving the above-shown system PYTHONPATH to the user env
What else am I missing? I don't understand.
All in all, what I needed to get this working:
system environmental variables
Path: C:\Path2Python27;C:\Path2Python27\scripts;C:\Path2Python37;C:\Path2Python37\scripts;
PYTHONPATH: C:\Users\Me\myscripts\py
and
making sure to use Andriy's comment. It won't work using python3 unzipit.py "C:\link\to\folder".

In order to achieve what you want you have to specify -m flag and the module name, so python will retrieve module by looking up python module path. See more here in interface-options. The command shall be:
python3 -m unzipit "C:\Users\Me\downloads\zipfilehome"

Why would I add python to PATH

I am beginning to look at python, so when I found a tutorial it said that the first thing to do would be to download python from www.python.org/downloads/
Now when I downloaded python 3, I then started the installation and got to
Why would I want to "Add Python 3.5 to PATH"? What is PATH? Why is it not ticked by default?

PATH is an environment variable in Windows. It basically tells the commandline what folders to look in when attempting to find a file. If you didn't add Python to PATH then you would call it from the commandline like this:
C:/Python27/Python some_python_script.py
Whereas if you add it to PATH, you can do this:
python some_python_script.py
Which is shorter and neater. It works because the command line will look through all the PATH folders for python and find it in the folder that the Python installer has added there.
The reason it's unticked by default is partly because if you're installing multiple versions of Python, you probably want to be able to control which one your commandline will open by default, which is harder to do if both versions are being added to your PATH.

In addition to what #SuperBiasedMan stated, you can edit your PATH in Windows by hitting Start > Run, then type sysdm.cpl.
From there, navigate to Advanced tab and then hit Environment Variables.
In the lower section, where it says 'System variables', find the one named PATH and double click it. Note that it would be easier to copy and paste it to a notepad or something. The separator as you can see is a semi-colon.
Any path that you add to this variable, will be looked when you type any command in a cmd window or through the 'Run' command line.
That's the same concept as in Linux, I just pointed out how it can be edited.

This shows the way if you haven't add python to PATH(By the way, the python.exe is in my Python directory)
This is the way if you add python to a PATH

Python Installation Location (Windows)

I need to find out if there is Python installed on the computer.
My specific issue is that I am distributing a program that comes with its own interpreter + standard library (the end-user may not have Python). In the installation, I am giving the option to use the user's own installed Python interpreter + library if they have it. However, I need the location of that. I can ask the user to find it manually, but I was hoping there was an automatic way.
Since my installer uses my included interpreter, sys.prefix refers to the included interpreter (I know this because I tried it out, I have Python 2.7 and 3.3 installed).
I also tried using subprocess.call: subprocess.call(['py', '-c', '"import sys; print sys.prefix"']) which would use the standard Python interpreter if there was one, but I'm not sure how to capture this output.
Thus, are there any other ways to find out if there is a default Python version installed on the user's computer and where?

Actually, in the light of my other answer, an even better way to find the Python installation directory would probably be to check the Windows registry, since the Python installer places some information there.
Take a look at this answer and this Python module.

Some users might have placed their local Python directory into the system's PATH environment variable and some might even have set the PYTHONPATH environment variable.
You could try the following:
import os
if "python" in os.environ["PATH"].lower():
# Confirm that the Python executable actually is there
if "PYTHONPATH" in os.environ.keys():
# Same as in the last if...
As for the subprocess.call(...), set the stdout parameter for something that passes for a file object, and afterwards just .read() the file object you gave to see the output from the call.

Add a directory to Python sys.path so that it's included each time I use Python

Currently, when trying to reference some library code, I'm doing this at the top of my python file:
import sys
sys.path.append('''C:\code\my-library''')
from my-library import my-library
Then, my-library will be part of sys.path for as long as the session is active. If I start a new file, I have to remember to include sys.path.append again.
I feel like there must be a much better way of doing this. How can I make my-library available to every python script on my windows machine without having to use sys.path.append each time?

Simply add this path to your PYTHONPATH environment variable. To do this, go to Control Panel / System / Advanced / Environment variable, and in the "User variables" sections, check if you already have PYTHONPATH. If yes, select it and click "Edit", if not, click "New" to add it.
Paths in PYTHONPATH should be separated with ";".

You should use
os.path.join
to make your code more reliable.
You have already used __my-library__ in the path. So don't use it the second time in import.
If you have a directory structure like this
C:\code\my-library\lib.py and a function in there, e.g.:
def main():
print("Hello, world")
then your resulting code should be
import sys
sys.path.append(os.path.join('C:/', 'code', 'my-library'))
from lib import main

If this is a library that you use throughout your code, you should install it as such. Package it up properly, and either install it in your site-packages directory - or, if it's specific to certain projects, use virtualenv and install it just within the relevant virtualenvs.

To do such a thing, you'll have to use a sitecustomize.py (or usercustomize.py) file where you'll do your sys.path modifications (source python docs).
Create the sitecustomize.py file into the \Lib\site-packages directory of your python installation, and it will be imported each time a python interpreter is launched.

If you are doing this interactively, the best thing to do would be to install ipython and configure your startup settings to include that code. If you intend to have it be part of a script you run from the interpreter, the same thing applies, since it will have access to your namespace.
On the other hand, a stand alone script should not include that automatically. In the future, you or some other maintainer will come along, and all the code should be obvious, and not dependent upon a specific machine setup. The best thing to do would be to set up a skeleton file for new projects that includes all of the basic functionality you need. That, along with oft-used snippets will handle the problem.
All of your code to run the script, will be in the script, and you won't have to think about adding that code every time.

Using jupyter with multiple environments, adding the path to .bashrc didn't work. I had to edit the kernel.json file for that particular kernel and append it to the PYTHONPATH in env section.
This only worked in that kernel but maybe this can help someone else.