The attached patch adds the ability to distutils to
have extensions stripped from scripts when they are
"built".  This adds an option, --strip-extensions, to
the build_scripts command which defaults to false; the
option is only honored on systems for which os.name ==
"posix" and sys.platform != "darwin".

While I generally like the idea of such a feature,
there are some open issues regarding this:

1.  To support legacy applications which install
scripts with extensions but which want the new option
to apply to more recently added scripts by default,
there needs to be a way to specify this on a per-script
basis.  I've not thought about how to do this yet, but
I'd generally prefer to have this option set in a
setup.cfg file included in a distribution.

2. Mac OS X appearantly still has some issues with the
differences between GUI and non-GUI applications, and
the extension on a script is being used to help
determine the context in which scripts should be run.

As a result, I think this feature should not be
accepted in this form, but warrants further thought to
make it easier to create a declarative way to specify
what the proper treatment of individual scripts should be.

I'm posting the patch so others can review it, and to
provide a record of these issues.

Logged In: YES 
user_id=2772

I've wanted another related feature:  I wrote an image
viewer program using pygame.  It works nicely on windows and
unix.

In the source tree, I named the script with a .py extension,
but when installing on unix I want no extension, and when
installing on Windows I want a .pyw extension.

Whatever scheme is developed for naming installed scripts,
it should also allow renaming to .pyw on Windows.

My own setup.py replaces build_scripts so that the scripts=
parameter to setup is a mapping {installed_name : source
name}, and provides two functions WINDOWED(s) and
TERMINAL(s) to return s plus the appropriate extension, if any.

Like Fred, I don't think this is an ultimate solution.

My setup.py can be viewed:
http://unpy.net/cgi-bin/viewcvs.cgi/xvp/setup.py

I doubt "strip-extensions" has to be in distutils.
Isn't a simple script like below enough for this?

    $ for i in *.py; do mv $i ${i%.py}; done

It makes sense to me but we need to look at setuptools console feature
nowadays.

I think it might be the right piece to add in distutils for console scripts.

Akira: Why require people to manually run this command instead of bundling it into distutils?  After all, install_scripts is just a cp, but distutils still does it :)

I wonder if this should be a built-in functionality like in Fred’s patch or an install hook shipped in a subpackage of distutils2, say contrib.hooks or ext.hooks.  Hooks have the nice properties of being small standalone pieces of functionality that are composable (think WSGI middleware), and this would also be a good hook example.

At this point, I'm more in favor of adopting something closer to the setuptools scripts based on "console_scripts" entry points, and dropping old-style scripts entirely (most *because* of the issues I mentioned at the start).

We’re going to follow setuptools’ lead and generate platform-appropriate script or binary files from callables.