On 16 July 2013 15:01, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
Vinay Sajip <vinay_sajip <at> yahoo.co.uk> writes:
>
> Not true for distlib - it doesn't add .exe wrappers to wheels at build time
>  It adds them to the target directory when installing under Windows. (You
> can also choose not to install any wrappers.)

Sorry, some misinformation there - distlib does do this when invoked via
distil. However, this can be turned off at the distlib level - I will update
distil to not do this when adding wheels.

OK. That sounds good.

I'm starting to become uncertain as to whether we actually have an issue here. I think:

(1) Builders can put anything they like into the scripts directory. That's more or less out of our control. From what I know of distil's approach,  it doesn't actually execute setup.py so it keeps a lot more control than (say) bdist_wheel, which effectively runs setup.py install to a temporary directory then bundles what it finds. But in essence, as things stand right now, the scripts directory of an arbitrary wheel could contain arbitrary stuff.
(2) Wheel installers should "make Python scripts work". All that I'm aware of fix up shebang lines and add execute bits. Only distlib adds exe wrappers, I believe. Others work on Windows because the builders put exe wrappers in place (see (1)) but that has some issues. I suspect there may be some "accidental" successes on Unix where setuptools scripts do or don't get a .py extension depending on the target platform, but I have no evidence of this myself.

So there's a lot of potentially platform dependent stuff in "scripts" and wheel builders don't (can't) recognise and encode this in the tags. Wheels mostly work at the moment because not many people use them cross platform. But there's potential for issues down the line.

FWIW, I believe that the whole "scripts" directory as a concept is too platform-specific. The only real use for it is to expose CLI applications, and a declarative approach like setuptools console_scripts entry points would be better. So longer term I'd argue for deprecating "scripts" altogether and replacing it with some form of "CLI entry point" metadata which may be exposed as part of metadata 2.0 or 3.0, or may simply be internal metadata communicated between the builder and the installer, but not exposed at the PyPI level. Oscar's email argues for exposing it as project metadata, though, and I can see the benefit.

Paul