<div dir="ltr"><div class="gmail_extra">On 16 July 2013 13:42, Ronald Oussoren <span dir="ltr"><<a href="mailto:ronaldoussoren@mac.com" target="_blank">ronaldoussoren@mac.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> On the other hand, I'm missing something, as I don't see how the *current* exe wrappers avoid meaning that there need to be separate 32-bit and 64-bit versions of pip...<br>

<br>
</div>Couldn't you just ship both variants of the exe wrappers in a single distribution and then use the correct one for the current installation? That's what I'm doing in py2app.</blockquote></div><br>That's OK for source-style installs (which is what setuptools does, and what pip mostly cares about right now). But for bundling with Python it needs to be considered (although it's just getting the right one in the right installer). But for wheels it's a pain, because instead of having just a single pip wheel, we need 32-bit and 64-bit wheels solely for the wrappers. That sucks. Hard. (And it's not just for pip, nose will have the same problem, as will many other projects that use exe wrappers). And the bdist_wheel command currently doesn't recognise this *at all*. So wheels using wrappers are potentially broken.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>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).</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>This is complex enough that I'm now concerned that we need reference "wheel install" code in the stdlib, just so that people don't make up their own on the basis that "wheel is simple to install manually" and screw it up. Also so that we only have one style of command line script wrapper to deal with going forward, not a multitude of mostly-compatible solutions.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Nick: See the above point re PEP 426 - do you agree that this needs addressing in Metadata 2.0?</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>
Paul</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>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.</div>
</div>