[Distutils] Wheels and console script entry point wrappers (Was: Replacing pip.exe with a Python script)

[Paul Moore]

On 16 July 2013 15:01, Vinay Sajip <vinay_sajip at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130716/28222a28/attachment.html>