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

[Mark Hammond]

On 2/07/2011 7:08 PM, Vinay Sajip wrote:
> Mark Hammond<skippy.hammond<at>  gmail.com>  writes:
>
>> The PEP does say "if possible, should be installed somewhere likely to
>> already be on the system PATH (eg., the Windows System32) directory."
>> It is silent about what to do when that isn't possible, but I'd think it
>> OK if the launcher was installed directly in the Python directory - IOW,
>> I'd think it OK if the PEP said "should be installed next to the
>> PythonXX.dll being installed" - but an important point in the above
>> working is the "already be on the system PATH" - ie, I don't really want
>> it put in a newly created directory unless the installer also adds that
>> directory to the PATH - and what to do on uninstall then becomes an issue.
>
> But "next to PythonXY.dll" implies multiple copies, which we want to avoid,
> right?

I believe this will be most useful when people select "install for all 
users", which will force it into system32.  If people select "just for 
me", then there will be multiple copies on disk, but only one will be 
active (ie, we will not support different ones being registered for 
different users.

It isn't ideal, but I think it good enough, avoids some complexity and 
should meet the needs of the majority of users.

>> One problem with all of this is uninstallation and specifically if the
>> user is uninstalling the most recent Python installation while leaving
>> earlier ones.  I guess there are 2 general answers to this:
>>
>> * The installer process could remember the previous association and
>> restore that on uninstall.
>
> We'd need to do that in the case of the earlier Python not having come with a
> launcher, i.e. when its version is<  3.3.

OTOH, we don't do that now AFAIK.

>> * We treat this as a "wont-fix" and document a work-around of asking the
>> user to reinstall the previous version to restore the file association.
>
> This is not ideal from a user's perspective.

Sure, but neither is the current situation - I don't recall enough users 
complaining about that to make the effort worthwhile.

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!

>> We probably need to be mindful of adding too much extra work for the
>> installer process as that may well end up blocking us on getting this
>> into the next appropriate release.  In particular, Martin's thoughts
>> here would be very useful.
>>
>> This would force the user to reinstall that older one to re-establish
>> the associations correctly
>
> It sounds onerous for users to have to reinstall an older Python.

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.

> I'm not that
> familiar with Windows Installer features, so I don't know if this is too fancy,
> but perhaps we could remember the last non-launcher association when we install
> the launcher, and either restore that when the launcher is uninstalled (if it's
> still pointing to an installed Python) or remove the association altogether,
> otherwise. If this logic is too fancy to include in the installer itself,
> perhaps we can provide this logic in the launcher itself or via an ancillary
> executable or DLL that the installer can just call into.

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

> Is there some mechanism like the SharedDLLs registry key for executables, which
> could be used to reference count launcher installations so that it could be
> uninstalled at the appropriate time? Could we perhaps used the SharedDLLs
> feature itself?
>
>> Yeah - I wonder if we can leverage the "job" api here and refuse to
>> start if there are already 2 processes in the job?  OTOH, that is tricky
>> as it would also prevent someone using os.startfile with a .py file....
>
> If there's only ever one launcher installed (which we could ensure by
> installing it in a Windows rather than a Python location)

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.

 > then perhaps we could
> perhaps check for the value of a customised command pointing at the one-and-
> only launcher, but this is circumventable. Anyway, perhaps we just need to
> handle a user error rather than someone deliberately trying to engineer
> recursion.

Yeah, I agree.

> Another approach might be - rather than limit the number of processes in the
> job, look to see if the launcher executable is already associated with an
> existing job. I'm not au fait with the job API, and hence unsure of how that
> would play with usages such as os.startfile, subprocess etc.

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'm not too bothered to be honest - the customized commands exist purely
>> for alternative implementations, so my initial thoughts are that
>> additional args would be as useful for them as they are for cpython
>> invocations.  IOW, if they don't need it, then CPython invocations don't
>> need it either, so maybe it can be dropped completely?
>
> I think they would be useful, so let me check the implementation again.
>
>> It will be a few days until I can look at the implementation, but I'm
>> very happy to see it started.  Given it is now ahead of the Python
>> reference impl, I wonder if we should just drop all wording about that
>> reference impl and just treat the C impl as canonical?
>
> Once you've taken a closer look, if you think it looks good enough, then that's
> fine. If you have a BitBucket account, I can add your account to the repo so
> you can push changes to it.

Great, thanks!

Mark