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

[Mark Hammond]

On 1/07/2011 7:20 PM, Vinay Sajip wrote:
> Mark Hammond<skippy.hammond<at>  gmail.com>  writes:
>
>> The intention is that there only be a single launcher, as only one app
>> can be associated with .py files.  OTOH though, file associations can be
>> configured per-user IIRC, and assuming that is the case, we could avoid
>> my multiple-ini-file usecase above by just allowing a different launcher
>> to be registered for a specific user.  This is sounding difficult from
>> the UI perspective though (ie, does the installer then need to ask that
>> question, will there be a post-install technique for per-user
>> registration, etc?)
>
> I don't like this, for the reasons you state. I think it would be better if the
> PEP was changed to say that there is intended to be just one launcher
> installation per machine. As the intention is for the launcher to ship with
> Python, and there can be multiple Pythons installed, I presume we'll have to
> handle this by installing the launcher in some common-to-all-Pythons location
> somewhere outside a Python installation location, such as "c:\Program
> Files\Python Launcher". This should be stated in the PEP, and we'll also need to
> indicate how the launcher will be cleaned up if for some strange reason someone
> uninstalls all Pythons from a machine. Then we can just state that there's a
> global .ini file (where the launcher is installed) and a local one (in the
> user's APPDATA). From that perspective, it makes sense to have items in the
> local (APPDATA) override the global (launcher installation location).

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.

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

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

> BTW I thought of another thing that perhaps needs handling: what if a customized
> command points to the launcher itself? It'd be turtles all the way down :-)

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

 From your second mail:

> I've assumed that if a customised command is provided with arguments in the
> shebang line, these will be ignored - if people want to run with different
> options they can always define more customised commands. If you agree with this,
> the PEP should probably explicitly state this.

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?

> In a couple of cases I've implemented using fixed size arrays - for the lists of
> installed Pythons and customised commands. Of course these can be made dynamic,
> but what's there is good enough for the moment for exploration.

Sure - I think there is some policy that a Python version number will 
never be > 10, so that sounds fine to me.  So long as the launcher 
doesn't blindly run off the end of such arrays I think it is fine - 
limitations can be addressed in later versions.

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?

Cheers,

Mark