There are two versions of launchers primarily because of my naiveté when addressing the UAC issue. 64-bit launchers were exempt from the UAC restrictions that caused them to launch in a separate window. I believed this to be a proper fix, when in fact those still using 32-bit launchers were still experiencing the problem. See https://bitbucket.org/tarek/distribute/issue/143/easy_install-opens-new-cons ole-cant-read for more detail.
So I agree, it would probably be sufficient to only supply 32-bit executables. However, my preference would be to supply architecture-appropriate executables rather than relying on a compatibility layer. Furthermore, I dont believe the ARM architecture has a compatibility layer (meaning 64-bit executables are required for 64-bit ARM builds), so architecture and word size distinction is necessary. I believe youre right about leveraging the py launcher. Id like for setuptools to not have to supply launchers at all but depend on py launcher instead. The py launcher is bundled with Python 3.3 so should become ubiquitously available soon. I believe setuptools can begin to rely on it and not supply a launcher at all. The scripts currently installed by setuptools are suitable for launching by py launcher, so all that will need to happen is to stop supplying its own launcher. At least, thats how I imagine it happening. From: Paul Moore [mailto:p.f.mo...@gmail.com] Sent: Tuesday, 16 July, 2013 09:32 To: Distutils; Jason R. Coombs Subject: Re: Wheels and console script entry point wrappers (Was: Replacing pip.exe with a Python script) On 16 July 2013 14:08, Paul Moore <p.f.mo...@gmail.com <mailto:p.f.mo...@gmail.com> > wrote: PS There is still the proviso that I haven't tested my assumption that the separate 32 and 64 bit wrappers are *needed* (setuptools and distlib use them, so I think it's a valid assumption, but I need to test). I will try to get time to check that ASAP. Hmm. I just did a quick test, and then based on the results checked the setuptools source code. I can see no reason why there needs to be 32 and 64 bit launcher exes. The launchers simply use CreateProcess to launch a separate Python process using the #! line of the script. So there's no DLL loading going on, and no reason that I can see for needing separate 32 and 64 bit builds. Jason - can you shed any light on why there are separate builds for 32 and 64 bits? Actually, the launcher is essentially identical to the "py" launcher for Windows, except that it gets a script name to execute from the name of the launcher. I'm wondering whether the correct approach here would be to enhance the launcher one more time to look for a suitably named script and auto-run it if it's present (i.e. merge the wrapper functionality into the launcher). Then we have a standard wrapper that everyone can use and not reinvent their own. Paul
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
