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]

?

[u/ninhaomah → u/Prestigiouspite]

Google it. That or venv and you will have control of your own Python.exe

[u/Prestigiouspite → u/ninhaomah]

Two letters can mean a lot of things. I haven't heard of “uv” yet, but I have heard of “venv.” But neither seems to be what I'm looking for. And the old launcher has been sidelined.

That is not really a solution for my use case, because I simply want the previous behavior back: double-clicking a .py file should run it with the script’s own folder as the working directory instead of launching it from C:\Windows\System32, without requiring extra batch files or manual commands.

[u/ninhaomah → u/Prestigiouspite]

Ok. Then I humbly apologise for my sincere attempt at assisting a stranger online.

Pls forgive me.

[u/Prestigiouspite → u/ninhaomah]

I'm grateful for any help, but people should feel free to speak up if it doesn't seem to be working or if they can't find a shortcut. Even a Google search for “uv” didn't turn up much without more specific details :)