[Python-Dev] PEP 397 (Python launcher for Windows) reference implementation (original) (raw)

Vinay Sajip vinay_sajip at yahoo.co.uk
Sun Jul 3 12:13:43 CEST 2011

Mark Hammond <skippy.hammond gmail.com> writes:

I'm not fundamentally opposed to doing something better here - I'm just trying to avoid this kind of stuff being a requirement for acceptance. If you are more familiar with the installer than I and feel it can be done simply, then I'm happy for you to go for it!

No, you're right - I'm just throwing ideas out. I'm not especially familiar with MSI in general, though I believe you can do the relevant things with logic in custom actions. AFAIK there are already custom actions used in the Python MSI, but I wouldn't want to propose any such changes to the MSI unless Martin were to make encouraging comments :-)

But this only happens when they install a later version, then uninstall the later one and continue to use the old one. I'd suggest that is (a) rare and (b) possibly already broken (ie, the old association may not be restored now). If the old association currently is correctly restored, then I'd expect things to just magically work in this new model without any effort.

As to (a), not uncommon scenarios would be (i) later version breaks something, so go back to earlier version, or (ii) using 2.x, installing 3.x to try out, going back to 2.x. I'm not sure about (b).

I'm still inclined to call YAGNI, but as above, I don't fundamentally oppose such bells-and-whistles.

You're probably right about the cost(effort)-benefit trade-off.

We probably can't ensure this while the installer supports a non-UAC installer (ie, the "just for me" option.) OTOH, I'm not sure the "just for me" option currently works without needing UAC elevation anyway. But assuming it does (or the intention is to fix things if it does not), then we can't guarantee a writable system32.

Okay. From a cursory glance at msi.py, UAC elevation appears to be requested.

Exactly - code doing os.startfile on a .py file will correctly cause the same launcher to be re-executed and preventing this would break such scripts. However, I think this would be extremely rare and the more usual case would be to use sys.executable. Indeed, any script using os.startfile for a .py file is already broken, even if the author doesn't know it yet :)

I had a closer look at the Job API, and it does seem to offer the required functionality, so we could tell whether the current process is in a job -> get all processes in that job -> get their executables and command lines -> see if recursion is occurring. However, would we class this as an implementation detail or does it need a mention in the PEP?

> I think they would be useful, so let me check the implementation again.

I've made some updates so the following works: with the configuration containing

[commands] shell=cmd /c

with a shebang in doit.py of '#!shell python -v'

the launcher will run 'cmd /c python -v doit.py'.

Regards,

Vinay Sajip

More information about the Python-Dev mailing list