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

[Oscar Benjamin]

On 16 July 2013 14:38, Paul Moore <p.f.moore at gmail.com> wrote:
> On 16 July 2013 14:30, Ronald Oussoren <ronaldoussoren at 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).

There are many other uses for console script entry point metadata. For
example, it would be good to be able to query pip/pypi in order to
find out which packages supply a particular console command. One
feature of Ubuntu that I really like is the way that it automatically
tells you how to install any missing command:

oscar:~$ pypy
The program 'pypy' is currently not installed. You can install it by typing:
sudo apt-get install pypy

Obviously it's not as useful when the command and the package have
exactly the same name :)

>>
>> 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
> :-(

I think that it should be mandatory.

It should be possible for someone releasing a script via pypi to
ensure that their program can be invoked after installation under a
name of their choosing (assuming the user has the Python Scripts/bin
directory in PATH). AFAIK the only bullet-proof way to do this on
Windows is with an .exe wrapper.

If you only want the program to be invokable from cmd and PowerShell*
then a .bat file should be fine. Depending on file extension to invoke
.py files with py.exe is subject to input/output redirection bugs on
some windows systems (this is solveable when using .py in PATHEXT
instead of file associations for cmd at least).

However, if you also want the program name to be invokable from e.g.
subprocess with shell=False or from git-bash or Cygwin or many other
things then neither .bat files nor PATHEXT are sufficient. Wrapper
.exes are necessary to ensure that this works properly.


Oscar


* I don't actually use PowerShell and cannot confirm that running .bat
files works fully i.e. without screwing up sys.argv encoding or
input/output redirection or anything else.