[Distutils] How to handle launcher script importability?

[Jason R. Coombs]

In Setuptools 1.0 (currently in beta), I've added an experimental, opt-in
feature to install pure Python launcher scripts on Windows instead of
installing a launcher executable for each script, with the intention that
these scripts will be launched by pylauncher or Python directly, eventually
obviating the need for a launcher executable in setuptools at all.

This means that instead of installing, for example:

  Scripts\my-command.exe
  Scripts\my-command-script.py
  Scripts\my-command.exe.manifest

Instead Setuptools just installs:

  Scripts\my-command.py

This technique is much like the scripts that get installed to bin/ on Unix,
except that due to the nature of launching commands on Windows, the .py
extension is essentially required.

One problem with this technique is that if the script is also a valid module
name, it can be imported, and because Python puts the script's directory at
the top of sys.path, it _will_ be imported if that name is imported.

This happens, for example, after installing Cython. Cython provides a
command, 'cython', and a (extension) module called 'cython'. If one launches
cython using the script launcher, the 'cython' module will not be importable
(because "import cython" will import the launcher script). Presumably, this
is why '-script' was added to the launcher scripts in previous versions.

This is a rather unfortunate situation, and I'd like to solicit comments for
a way to avoid this situation. I see a few options:

1. Have the setuptools-generated launcher scripts del sys.path[0] before
launching.
2. Accept the implementation and file bugs with the offending projects like
Cython to have them either rename their script or rename their internal
module.
3. Continue to generate the script names with '-script.py' appended,
requiring invocation to always include -script.py on Windows.
4. Continue to generate executables, duplicating the effort of pylauncher,
and dealing with the maintenance burden of that functionality.

I don't see (2), (3), or (4) as really viable, so my proposal is to move
forward with (1) if there aren't any better suggestions.

If we move forward with (1), there are a few concerns that come to mind.

First, this approach would not apply to package-supplied scripts. What
should be done about those (if anything)?

Second, this would apply to Unix and Windows scripts (I'd rather not make
the distinction if possible) - are there any concerns about removing
sys.path[0] in the launch scripts on Unix? 

Third, is it possible some users are depending on the presence of
sys.path[0] or the assumed positions of other items in sys.path that should
be protected by this change? Would it make sense to replace sys.path[0] with
a non-existent directory instead?

My instinct is that these concerns are not of sufficient importance to
account for them, and that we should just implement (1) as simply as
possible.

Your comments and suggestions are appreciated.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6572 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130811/5737bcda/attachment.bin>