classification
Title: Stripping script extensions with distutils
Type: enhancement Stage: resolved
Components: Distutils2 Versions: Python 3.3
process
Status: closed Resolution: duplicate
Dependencies: Superseder: packaging: generate scripts from callable (dotted paths)
View: 12394
Assigned To: tarek Nosy List: akitada, eric.araujo, fdrake, jepler, tarek
Priority: normal Keywords: needs review, patch

Created on 2004-06-21 16:40 by fdrake, last changed 2011-06-24 12:23 by eric.araujo. This issue is now closed.

Files
File name Uploaded Description Edit
strip-script-extensions.patch fdrake, 2004-06-21 16:40
Messages (7)
msg46202 - (view) Author: Fred L. Drake, Jr. (fdrake) (Python committer) Date: 2004-06-21 16:40
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.
msg46203 - (view) Author: Jeff Epler (jepler) Date: 2004-08-07 14:27
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
msg81073 - (view) Author: Akira Kitada (akitada) Date: 2009-02-03 17:09
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
msg81078 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-02-03 18:16
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.
msg117684 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-09-30 01:17
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.
msg117725 - (view) Author: Fred L. Drake, Jr. (fdrake) (Python committer) Date: 2010-09-30 11:49
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).
msg138936 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-06-24 12:23
We’re going to follow setuptools’ lead and generate platform-appropriate script or binary files from callables.
History
Date User Action Args
2011-06-24 12:23:48eric.araujosetstatus: open -> closed
versions: + Python 3.3, - 3rd party
superseder: packaging: generate scripts from callable (dotted paths)
messages: + msg138936

resolution: duplicate
stage: patch review -> resolved
2010-09-30 11:49:17fdrakesetmessages: + msg117725
2010-09-30 01:17:25eric.araujosetversions: + 3rd party, - Python 2.4
messages: + msg117684

keywords: + needs review
type: enhancement
stage: patch review
2010-04-09 07:46:06tareksetnosy: fdrake, jepler, tarek, eric.araujo, akitada
components: + Distutils2, - Distutils
2010-04-09 01:44:19eric.araujosetnosy: + eric.araujo
2009-02-03 18:16:19tareksetassignee: tarek
messages: + msg81078
2009-02-03 17:09:29akitadasetnosy: + akitada, tarek
messages: + msg81073
2004-06-21 16:40:56fdrakecreate