On 16 July 2013 14:30, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
> I think the correct solution is to explicitly have declarative support for "console script entry point" metadata in PEP 426, as well as having tools like bdist_wheel and distil do some explicit backward compatibility hacking to remove legacy-style exe wrappers. The wheel install code should then explicitly install appropriate wrappers for the target platform (which may be exe wrappers similar to the current ones, but moving forward may be some other mechanism if one is found).

Yikes, that means my assumption is wrong. The section on "Recommended installer features" in the wheel spec[1] says that the wrapper executable should be created on installation, does pip not do this?

Yes, Nick pointed me at that part of the PEP. Nobody's doing that at the moment, and exes are being added to the wheels at wheel build time, which is also wrong.

That'll teach me to work from reality rather than specs :-(

Daniel, Vinay, pip developers - it looks like we need to do some work in this area to make the code conform to the specs. The PEP only says this is a "recommended" feature, but frankly I think it needs to be mandatory, or script wrappers are going to be a mess we'll be dealing with for some time :-(

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

That depends on what the wrapper does, if it launches a regular python with the right command-line you might be able to get away with a single wrapper, if it loads python.dll and executes the script directory you do need separate wrappers for 32 and 64 bit.

As I said in another message, looks like there's no real reason for separate wrappers. A 32-bit one should work regardless [1]. But wheels built on 64-bit systems at the moment won't work on 32-bit ones (because the wrappers will be 64-bit).

[1] With the possible exception that Windows' magic shadowing of 32 and 64 bit "stuff" - the WOW64 magic that I know nothing about - could cause odd results in obscure cases. I propose ignoring this in the absence of actual bug reports :-)

Paul