| msg46202 - (view) |
Author: Fred Drake (fdrake)  |
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 ii i{i%.py}; done |
|
|
| msg81078 - (view) |
Author: Tarek Ziadé (tarek) * |
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) * |
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 Drake (fdrake) |
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) * |
Date: 2011-06-24 12:23 |
| We’re going to follow setuptools’ lead and generate platform-appropriate script or binary files from callables. |
|
|