> Short review of the superseded bugs.
> 
> #870479 — Scripts  need platform-dependent handling
> A request to remove .py on POSIX and create  a .cmd file on Windows.  The .cmd 
>part was quickly shot down (see bug  thread for problems), and the discussion 
>moved to the setuptools  generation.  Interesting comment by a Windows user:
> > In principle I  don't have a problem with the automatic generation of an
> > EXE (I assume  it generates a shell script with no extension on Unix?)
> > but it should be  done in such a way that the EXE is version-independent.
> > This is  necessary to ensure that pure-python packages, when made into
> >  bdist_wininst installers, continue to be version-independent. (At the
> >  moment, distutils generates version-dependent bdist_wininst packages
> >  *only* for C extensions. Setuptools generates version-dependent
> >  installers all the time, which is a pain).

I don't see how it makes sense to aim for version independence, especially since 
2.x and 3.x can each raise SyntaxErrors when presented with the other's code. 
Isn't explicit better than implicit here?

> > This may mean that a  reimplementation is required, rather than copying
> > the setuptools  code.

There's not much sense in making a simplistic copy, that's for sure.

> The bug links to a thread on distutils-sig, where we can find one  more issue 
>by Robert Kern:
> > In the generated script, please use "if  __name__ == '__main__':" to
> > block out the executable bits. Currently,  multiprocessing does not
> > work on Windows when the application is started  by a console_script.
> > Because Windows does not have a true fork,  multiprocessing will start
> > up clean Python subprocesses that import the  __main__ of the parent
> > process.
> (http://mail.python.org/pipermail/distutils-sig/2009-February/010981.html)
> 

FYI I have a "scriptize" script that generates scripts for entry points, example 
is at https://gist.github.com/1044799 which is Windows-friendly (it doesn't 
refer to "xxx-script.py" in usage messages, for example), and may be of 
interest.

> So, Tarek and Fred  have expressed support for the setuptools generation in a 
>handful of bug reports  and emails, and a number of users report they like it.  
>IIUC, setuptools  supports using python vs. pythonw on Windows (console vs. 
>GUI), but is not  flexible enough about which Python version to use, and does 
>not support  installing into bin vs. sbin on UNIX (see 
>http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard to learn more  about 
>/bin, /sbin, /usr/bin and /usr/sbin).  The cli.exe and gui.exe files  look like 
>they can be reused, but the install_scripts code will require more  work.
> 

For  the /bin, /sbin, /usr/bin or /usr/sbin issue, sure - but doesn't it make 
sense to do the other stuff in build_scripts?