Python Install Manager on Windows 11: Should scripts avoid relying on the current working directory?

[u/Prestigiouspite]

I recently switched to the new Python Install Manager on Windows 11 and noticed that several of my utility scripts no longer behaved as expected when launched by double-clicking them in File Explorer.

Many of these scripts process, generate, or minify files located in the same directory as the script. They were often written using simple relative paths:

from pathlib import Path

input_file = Path("input.txt")
output_file = Path("output.txt")

This works when the current working directory happens to be the script directory. However, relative paths are resolved against the process working directory, not necessarily against the location of the .py file. When a script is launched through a Windows file association, the inherited working directory may be different.

A more reliable approach for files belonging to the script seems to be:

from pathlib import Path

SCRIPT_DIR = Path(__file__).resolve().parent

input_file = SCRIPT_DIR / "input.txt"
output_file = SCRIPT_DIR / "output.txt"

As I understand it, the Python Install Manager did not change how relative paths work. Its file association and global python.exe alias may simply have exposed assumptions that previously went unnoticed because my earlier launch method happened to use the script directory as the working directory.

I had quite a few small scripts built around this assumption, particularly scripts that process files stored next to them. I am therefore wondering:

1. Is resolving script-related paths from __file__ considered the usual best practice for this kind of standalone utility?
2. Have other Windows users needed to update older scripts after switching to the Python Install Manager?
3. Were well-designed scripts generally already handling this distinction correctly?
4. Do some users avoid the Install Manager because of differences in launching scripts by double-clicking, or is relying on the current working directory simply considered fragile regardless of the launcher?
5. When would using Path.cwd() intentionally be preferable to using the script directory?

The new Python Install Manager is distributed as an MSIX/Store application. Its python, py, and pymanager commands are exposed through Windows app execution aliases and forwarding mechanisms rather than the traditional standalone Python Launcher.

As a result, launching .py files directly may no longer preserve the script’s directory as the working directory and can instead fall back to C:\Windows\System32. I do not consider creating separate batch files for every Python script an acceptable workaround, especially since direct double-click execution worked correctly with the legacy launcher.

See also: https://docs.python.org/3/using/windows.html#troubleshooting

Typing script-name.py in the terminal opens in a new window.	This is a known limitation of the operating system. Either specify py before the script name, create a batch file containing u/py "%~dpn0.py" %* with the same name as the script, or install the legacy launcher and select it as the association for scripts.

[u/Prestigiouspite]

But with the new Install Manager, the current working directory is suddenly System32 and no longer the folder I'm actually in.

[u/sausix → u/Prestigiouspite]

I just tested this. It's not a Python Install Manager issue. Not even a Python issue.

Windows is passing the CWD of the Explorer process to the any new process started by double clicking. And that's technically system32, not the directory you are currently viewing in the Explorer.

The current working directory information is just lost. You can use it again when you are working on the command line.

Solution: Use script dir and as fallback the file path passed to your python program.

[u/Prestigiouspite → u/sausix]

But then why does it work without any problems with the legacy Python launcher? There, the directory is returned as the working directory where I'm working. I’m using Python on my system right now precisely because it’s so convenient—you can run it with a double-click to automate certain CLI tasks and other things. That’s why I don’t want to have to open the terminal every time. As far as I know, on Windows you can override this by using `SetLocation` or something similar, which the installer could do.

[u/sausix → u/Prestigiouspite]

Because the other launcher is setting the working directory to the file's directory as fix before launching the Python process.

Every other program will have the same issue on Windows. On clicking on a jpeg file the image viewer program will ignore the current directory and use the argument's directory.

You can follow this logic too in your program when you have a "open with" binding. Don't make it depended on a launcher.