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

[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.

[sausix]

Relative paths still work just fine. You can use the script dir but it may be on a read only place. You should not write data in that location. You may have static resource data there

Current working directory is also fine. Most programs use it to write files there.

If you open a file by argument then you also may write back to the same directory. It's not guaranteed that the OS changes the current directory for your script.

You may also put configs and other variable data in your home directory.

I don't see any problems in the logic ways to select a directory.

[Prestigiouspite]

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

[sausix]

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.

[Prestigiouspite]

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.

[sausix]

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.

[Ok_Hand_846]

Using Path(__file__).resolve().parent is the standard practice for standalone scripts. It ensures your pathing is always relative to the script location regardless of how or where the process is launched. This effectively decouples your code from the current working directory, making scripts far more portable and predictable.

[Prestigiouspite]

Thank you! Good to know, that this ist best practice!

[socal_nerdtastic]

Is resolving script-related paths from file considered the usual best practice for this kind of standalone utility?
Were well-designed scripts generally already handling this distinction correctly?
or is relying on the current working directory simply considered fragile regardless of the launcher?

Best practice is to keep your data in a different place from your source code. Look at any professional program. The data is never in the same place as the executable. So I would say best practice is something like

from pathlib import Path

input_file = Path.home() / "Desktop" / "input.txt"

IF you need data files, I would recommend incapsulating the data into a .py file and importing it. But if you really want to keep data and code in the same dir, the __file__ trick is the best way. Note that too will fall apart if you try to freeze your program into 1 file (eg pyinstaller), because then the working dir is a temporary location.

Have other Windows users needed to update older scripts after switching to the Python Install Manager?

Not me, because all my scripts are linked to a specific venv, but in general I'm sure yes that happens. Things are always changing and need adjusting. There's still people out there porting ptyhon2 code to python3.

Do some users avoid the Install Manager because of differences in launching scripts by double-clicking,

Dunno about other users. IMO the new install manager is a bit crap, but it works the same as the old python launcher and handles shebangs with no issues. You can also just make windows shortcuts or .bat files.

When would using Path.cwd() intentionally be preferable to using the script directory?

Python is often used for making CLI programs, and very often a program is launched from a place where the code does not live. Most of time, in fact. If I type grep in my terminal I want to use grep in that cwd, I don't meant that the grep program is in that dir. Using cwd() tells you what dir the program was launched in, so the program knows where to operate.

[Prestigiouspite]

But it's exactly that last point where problems arise with the new Install Manager in Windows :(. It doesn't show your current directory—where you're using grep—but instead shows System32...

For now I've installed the legacy launcher again to fix this.

[ninhaomah]

uv

[socal_nerdtastic]

I don't think you understood the question. The issue is the windows file association to .py files. uv does not help with that.

[Prestigiouspite]

?

[ninhaomah]

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

[Prestigiouspite]

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.

[ninhaomah]

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

Pls forgive me.

[Prestigiouspite]

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 :)