<div dir="ltr"><div class="gmail_extra">On 16 July 2013 22:41, Vinay Sajip <span dir="ltr"><<a href="mailto:vinay_sajip@yahoo.co.uk" target="_blank">vinay_sajip@yahoo.co.uk</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 id=":18v" style="overflow:hidden">If the PEP is updated to include the exports, they should be in the wheel no<br>

matter which tool builds it. Then in theory distlib could generate the<br>
scripts during installation, but there are a lot of options to consider -<br>
did setuptools put them in there already? Do we want native launchers? etc.<br>
which is perfectly doable in distlib, but I'm not sure that's the best place<br>
for it because I think wheel processing should be uncomplicated.<br>
Wheel.install already has quite a few kwargs:</div></blockquote></div><br>I really don't want the wrappers to be present in the wheel, because if they are the wheel becomes architecture-specific. Also, consider that Unix targets should have the actual scripts written with no extension, whereas Windows targets should have foo-script.py and foo.exe. That should be decided at install time, bot at wheel creation time.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">As regards version-specific scripts, I'd assume it's the project's job to specify precisely what scripts they want. On that one, I'm on the side of providing infrastructure, not setting policy. Although I could be persuaded otherwise if there was a PEP on what commands a distribution should provide. In that case, let the project provide the command names, and let the installer implement the standard versioned-executable policy.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Paul.</div></div>