Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
On 2/07/2011 7:08 PM, Vinay Sajip wrote: Mark Hammond 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
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
Mark 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
Mark Hammond gmail.com> writes: > 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've now checked, and it appears that we don't do the right thing now anyway. On a clean Win7-x64, I installed Python 2.7 (32-bit), for all users, with registration of extensions - and Python.File etc. were added to the registry pointing at Python 2.7. I then installed Python 3.2 the same way, and rhe registry entries then pointed to 3.2. I then uninstalled 3.2, and the registry entries were gone! No magical restoration to the earlier values :-( Okay - if users have to do this now anyway, we at least wouldn't be naking things worse :-) Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
On 30 June 2011 13:50, Paul Moore wrote: > On 30 June 2011 12:13, Michael Foord wrote: >> I have that email (the update one from Mark not the silent nodding from Tim) >> still sitting in my inbox waiting for me to properly read through and >> comment on... Sorry for being useless, I'll try and move it up the priority >> list. >> >> I really like the PEP and think it will be a *huge* step forward for Windows >> users - so it's purely the details that need thrashing out (heh). > > That's my situation, too. I'll try to look through it properly in the > next day or two. OK, having looked through this, it looks pretty solid to me. I might try installing Vinay's implementation and seeing how it feels in use, as well... On restoring associations, I think it's entirely reasonable not to bother. It would be nice if py.exe remained installed as long as any (all-users) Python installation remained on the PC, but this may be complicated (given that older versions won't uninstall it) so maybe don't even bother with that. Actually, I'd question whether this shouldn't be packaged as a separate application, available as an independent download from python.org (I do think it's important enough to be hosted on python.org rather than PyPI, though). Future versions of python could bundle it as well, but that could be purely for convenience and to ensure that users don't miss it. If Python does bundle it, then I'd suggest that it remain a separate item in add/remove programs. That allows the user to choose whether to uninstall it or not. As py.exe and python live in separate directories (except in per-user installs) the installers don't have any nasty interactions like who deletes the directory to worry about. If you want to bother with an "active installation count" mechanism (whether SharedDLLs or a simple count/listing in the py.ini file, or something else) then when the count hits "No", just offer the user the choice to uninstall as part of the Python uninstall. I'd be inclined not to worry too much about per-user installations. Are per-user file associations possible? I've never used them, myself. As a simple approach, just install py.exe alongside python.exe in the user dir, don't worry about it being on PATH or having a separate add/remove programs item, and let the user do what he wants with it. Of course, if someone with more experience of per-user installs and the sorts of environment where they are needed wants to suggest something different, believe them rather than me! Basically, my feeling is that the core functionality is fine. Nothing in this will make life worse for anyone, so we can safely leave corner cases to be addressed later (with a standalone release, if it's urgent enough). Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
Paul Moore gmail.com> writes: > OK, having looked through this, it looks pretty solid to me. I might > try installing Vinay's implementation and seeing how it feels in use, > as well... Do have a play, it would be nice to get feedback. It's only available as source, though - is that OK? > I'd be inclined not to worry too much about per-user installations. > Are per-user file associations possible? I've never used them, myself. Yes, and they can be problematic: see http://www.deadlybloodyserious.com/2007/05/no-script-arguments/ where the problem described has also bitten me. I've no idea what put that association in the registry. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
On 3 July 2011 19:20, Vinay Sajip wrote: > Paul Moore gmail.com> writes: > >> OK, having looked through this, it looks pretty solid to me. I might >> try installing Vinay's implementation and seeing how it feels in use, >> as well... > > Do have a play, it would be nice to get feedback. It's only available as > source, > though - is that OK? No problem - I can build it from source. >> I'd be inclined not to worry too much about per-user installations. >> Are per-user file associations possible? I've never used them, myself. > > Yes, and they can be problematic: see > > http://www.deadlybloodyserious.com/2007/05/no-script-arguments/ > > where the problem described has also bitten me. I've no idea what put that > association in the registry. Ugh. That's nasty. It doesn't even look like a standard file type association. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Extending documentation innacuracies
Hi, While reading through the Extending and Embedding docs for Python 3.2 I've noticed something. While the "Py_InitModule" does not exists on Py3k, it is still mentioned on the docs: http://docs.python.org/py3k/extending/extending.html#keyword-parameters-for-extension-functions http://docs.python.org/py3k/extending/windows.html#a-cookbook-approach http://docs.python.org/py3k/faq/extending.html#what-does-systemerror-pyimport-fixupextension-module-yourmodule-not-loaded-mean Should I report a new issue? -- Alejandro Santos http://alejolp.com.ar ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extending documentation innacuracies
On Mon, Jul 4, 2011 at 9:24 AM, Alejandro Santos wrote: > Should I report a new issue? Yes please, tracker items are the best way to get that kind of oversight cleaned up. Thanks for noticing! Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: no one passes NULL here (or should anyway)
On Mon, Jul 4, 2011 at 8:02 AM, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/bbbeddafeec0 > changeset: 71160:bbbeddafeec0 > user: Benjamin Peterson > date: Sun Jul 03 17:06:32 2011 -0500 > summary: > no one passes NULL here (or should anyway) > > files: > Python/ceval.c | 3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > > diff --git a/Python/ceval.c b/Python/ceval.c > --- a/Python/ceval.c > +++ b/Python/ceval.c > @@ -1115,9 +1115,6 @@ > > /* Start of code */ > > - if (f == NULL) > - return NULL; > - May need to replace that with an assert(f != NULL) to keep static analysers happy. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: no one passes NULL here (or should anyway)
2011/7/3 Nick Coghlan : > On Mon, Jul 4, 2011 at 8:02 AM, benjamin.peterson > wrote: >> http://hg.python.org/cpython/rev/bbbeddafeec0 >> changeset: 71160:bbbeddafeec0 >> user: Benjamin Peterson >> date: Sun Jul 03 17:06:32 2011 -0500 >> summary: >> no one passes NULL here (or should anyway) >> >> files: >> Python/ceval.c | 3 --- >> 1 files changed, 0 insertions(+), 3 deletions(-) >> >> >> diff --git a/Python/ceval.c b/Python/ceval.c >> --- a/Python/ceval.c >> +++ b/Python/ceval.c >> @@ -1115,9 +1115,6 @@ >> >> /* Start of code */ >> >> - if (f == NULL) >> - return NULL; >> - > > May need to replace that with an assert(f != NULL) to keep static > analysers happy. Surely static analyzers don't assume every argument passed in is NULL? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: no one passes NULL here (or should anyway)
On Mon, Jul 4, 2011 at 12:54 PM, Benjamin Peterson wrote: > 2011/7/3 Nick Coghlan : >> May need to replace that with an assert(f != NULL) to keep static >> analysers happy. > > Surely static analyzers don't assume every argument passed in is NULL? I didn't check - was this change in a static function? For those, I think they can figure it out. For functions exposed to the linker, I think they demand an explicit check for a non-NULL pointer (which may be in the form of an assertion). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: no one passes NULL here (or should anyway)
2011/7/3 Nick Coghlan : > On Mon, Jul 4, 2011 at 12:54 PM, Benjamin Peterson > wrote: >> 2011/7/3 Nick Coghlan : >>> May need to replace that with an assert(f != NULL) to keep static >>> analysers happy. >> >> Surely static analyzers don't assume every argument passed in is NULL? > > I didn't check - was this change in a static function? For those, I > think they can figure it out. For functions exposed to the linker, I > think they demand an explicit check for a non-NULL pointer (which may > be in the form of an assertion). If someone's static analysis tool starts complaining about it, I'd be happy to consider adding an assert... -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
Mark Hammond wrote: On 2/07/2011 7:08 PM, Vinay Sajip wrote: perhaps we could remember the last non-launcher association when we install the launcher, It might be better to look in the registry for other Python installations and ask the user which one to restore if there is more than one. Trying to restore the "last" one would be prone to breakage if the user didn't uninstall versions in precisely the reverse of the order of installation. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
On 4/07/2011 3:59 PM, Greg Ewing wrote: Mark Hammond wrote: On 2/07/2011 7:08 PM, Vinay Sajip wrote: perhaps we could remember the last non-launcher association when we install the launcher, It might be better to look in the registry for other Python installations and ask the user which one to restore if there is more than one. Trying to restore the "last" one would be prone to breakage if the user didn't uninstall versions in precisely the reverse of the order of installation. While that makes alot of sense, the fact we are already "broken" in exactly the same way means I hope we can treat the restoration of associations as a separate issue - a worthwhile one, but not a pre-requisite for this PEP being approved. Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
