> I think here you're in a very small minority who could get away with this, and so I'd hesitate to make it sound like the recommended approach.

Well, the evidence here is that maybe even I shouldn't be doing this :-)

> What I'd actually recommend (on Windows) is to bundle a copy of Python with your application.

That's actually precisely what I'm doing. But I don't exactly have an "application", in the sense that I suspect you mean, which is the difficulty.

I'm trying to address the problem that it's a real pain to ship Python scripts as "utilities" on a Windows system. You want such scripts to still be plain text, because you typically hack on them a lot. You can't rely on shebangs and the launcher, because I continually find that PATHEXT doesn't include ".py" so they don't run properly, and "py name_of_script.py" doesn't do path searches. And anyway, I don't want to run the scripts with my system Python, because I don't want to dump all my dependencies in there.

So what I have is a small stub, that looks for a .py file of the same name, alongside the executable (so myutil.exe looks for myutil.py). Rather than using the system Python, it looks for a copy of Python in a subdirectory next to the script, and uses that. I can then install dependencies in the dedicated interpreter.

(And yes, PEP 582 would help make things easier in this area, too, but it never gained enough traction.)

I use the embedded distribution as that interpreter. I may be able to use a virtualenv instead, but I've not tried that yet.

Multiple copies of the launcher, one per script, and you're done :-)

To be honest, it really sucks that this is the most reliable way of managing small utility scripts in Python on Windows. But every other solution I've tried has had its own issues. I'd *much* prefer something standard, but I don't know how to bundle this in a way that makes it straightforward for "ordinary" users, so I've decided just to solve my own problem and leave it at that :-)