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

[Vinay Sajip]

Mark Hammond <skippy.hammond <at> 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