Re: [Distutils] Installing scripts

On Thursday 10 June 2004 04:06 pm, Tim Peters wrote:
Agreed.
be hostile to hide them in a hard-to-spell-in-a-DOS-box directory (like anywhere under the space-ridden "Program Files").
What's a little hostility among Windows users? They're used to it. :-) Seriously, though, I agree. "Program Files" is hostile in general for anyone using a command line.
I'm actually pretty OK with this. It's slightly distasteful, but survivable.
If the build_scripts command wants to strip .py extensions on non-Windows boxes, that's fine by me.
Cool.
Again, agreed. We just need to make sure the .py is there on Windows and not on installed scripts on Unix.
This brings up a related question: If a distribution provides scripts that end with .pyw, should they be omitted from the builld/installation on non-Windows platforms (possibly with a warning to the user)? Do we want a way to tell distutils about platform-specific scripts so they don't get installed on platforms to which they don't apply? -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

On Thu, Jun 10, 2004 at 04:27:29PM -0400, Fred L. Drake, Jr. wrote:
At first I did to...
But then I read this and considered that sometimes script==application, while other times script==background_utility. I would think Windows users would like "applications" to appear in the start menu, while "behind the scenes" utility scripts live quietly and invisibly elsewhere. I don't really see "scripts in a DOS box" as a typical Windows use of Python stuff. That may be my bias as my Python on Windows experience is pretty much limited to PySol ;) Maybe we need to consider some kind of "menu" support module that conforms to freedesktop.org menu standards (GNOME & KDE are jointly working on this and I suspect, or at least hope, Linux distros will support it as well.) on *nix targets and "Start Menu" on 'doze. I would suppose that the application installer would have to somehow register where the utility scripts live (presumably the install directory or a subdir there-of). I'm fairly certain this is a non-trivial excercise, and should be dealt with independent from the file extension issue.
I think the word you're searching for is "practical" <g>. Whatever the "Windows experience" might be, Distutils has to live down to it.
I'm not sure I agree. If a developer wants to distribute a Python in a DOS box for Windows, Distutils certainly shouldn't prevent it. A simple, scriptable Python text only IRC client might be popular (but this is from a guy who has a Cygwin rxvt under ssh-agent launched in his rarely-booted XP autostart ;)
Too lazy to go look at the PEP, but isn't "supported platforms" one of the metadata fields? If not specified, it should be "any" and if .pyw's exist it should include (maybe default to?) win32. If something has .pyw's AND supports other platforms as well, then not explicitly specifying the supported platform information (which could _still_ be "any") should be an error. How other platform support is implemented in such a case should be up to the author. Trying to make Distutils smart enough to second-guess the author's intent, or the package's capabilities, would be problematic at best. OTOH, a boolean GUI tag for scripts might be beneficial for cross-platform menu integration, so ... I'll stand firm on the "maybe" side of the question. mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/

Did we reach any conclusions regarding script installation? I think there are still some issues. I *think* we agreed that stripping a .py extension for scripts on Unix is acceptable, but it's not clear that any Unix-oriented users other than myself were involved in the discussion. I don't think we can simply rip off .py extensions on Unix, since that changes the set of installed names for packages that support older versions of Python/distutils; there probably needs to be some explicit gesture that this is desired in the call to distutils.core.setup() (or maybe just in setup.cfg). I asked about silently not installing .pyw scripts on Unix, but I've not seen any responses on that issue. I'd like to have a better idea of how much agreement there might be before starting to work on a patch. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

On Monday 14 June 2004 05:28 pm, Fred L. Drake, Jr. wrote:
I'm a Linux guy myself, and I prefer the .py extensions. I figure you can always make a symbolic link to a filename without the extension if you like. All my Python scripts have .py extensions. Of course, all my bash scripts have .sh extensions, too. I don't know what the norm is, but that's my 2 cents. Regards, .... Bob

On 15-jun-04, at 3:59, Bob Kimble wrote:
The norm is that scripts don't have extensions, that's why you use 'zgrep' and not 'zgrep.sh' ;). The implementation language is not interesting for the user of your script. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173

On 14-jun-04, at 23:28, Fred L. Drake, Jr. wrote:
I'm fine with that (as a unix- and mac-oriented person).
Please don't, unless MacOS X is treated differently than other unices. There is a minor difference between GUI and non-GUI scripts on OSX (due to a misfeature of the OS). Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173

On Tuesday 15 June 2004 01:07 am, Ronald Oussoren wrote:
--sigh-- So as I understand it, you'd need an extension to be left on for .pyw scripts, but could tolerate removal of extensions for other scripts. This is a distinct case from other Unixes and from Windows. I have a patch that will strip extensions for POSIX platforms other than Darwin (including Mac OS X), only if "build_scripts --strip-extensions" is used. Given the special cases and another issue related to legacy support, I'm not going to apply the patch. The other issue is one of supporting scripts that want to keep their extension (because they need to be command-line compatible with how they were previously installed) at the same time as providing scripts with extensions stripped by default. My own expectation is that I'd want to ship a setup.cfg file that set this by default, but I'd want to exclude specific scripts. This indicates that the simple model of a boolean flag isn't sufficient. I've posted my patch with a brief summary of these issues in the Python patch tracker on SourceForge: http://www.python.org/sf/976869 -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

On 21-jun-04, at 18:54, Fred L. Drake, Jr. wrote:
I really have to start reading my own mails some time... What I tried to say is "please don't ignore scripts with a .pyw extension in the scripts argument of setup". With MacOS X it all depends on how you look at things :-). If you want to start scripts by double-clicking on them they should have an extension (either .py or .pyw), if you're a unix-head that starts scripts from the shell the extension is annoying. IMHO the only correct way for installing GUI programs on MacOS X is creating an application bundle (which is a directory with a special structure). But that's just one opinion, and not necessarily relevant for this discussion. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173

On Jun 21, 2004, at 12:54 PM, Fred L. Drake, Jr. wrote:
Please don't make this special exception for sys.platform=='darwin'. - You can't browse to /usr/local/bin from Finder, anyway - It's almost impossible to write a useful GUI application without wrapping it in an application bundle in OS X -bob

Tim just pointed this thread out to me, so I thought I would try and keep it alive :) [Fred wrote]
How about something like: strip_extensions = {"posix": "txt py pyw", "darwin": "txt" } Where strip_extensions is a dictionary, keyed by the platform name (either sys.platform or os.name - whatever makes sense. The value is the list of extensions that should be stripped. This allows README.FIRST etc to remain intact, and allows fine control over what platforms it is applied to. The downside is that it can't really be spelt on the command-line. However, I argue that anyone who needs such fine grained control will have somewhere more suitable to specify it anyway. Would that make sense? Mark.

On Thursday 01 July 2004 09:59 pm, Mark Hammond wrote:
Tim just pointed this thread out to me, so I thought I would try and keep it alive :)
Good timing! I'be been thinking about this just this evening.
So how do you spell "I want the extension stripped from this one file on one platform, and that's it."? I'm also confused by your inclusion of "txt"; does this apply to all file copies, just scripts, or some magically determined set of file copies? I think the answer is that we want something similar to the Extension class for scripts, to give us a "bag" for script-specific options. I don't see any reason to extend extension-stripping beyond scripts. If we have a Script class that parallels Extension, that could encapsute some of the script-specific options. Listing scripts with just paths instead of Script instances would cause the current behavior to be used (which should also be what's used for just Script('path/scriptname.py')). That would allow something like this in setup.py: from distutils.core import setup, Script setup(name='Some Python Utilities', packages=['mytools'], scripts=[Script('bin/dostuff.py', strip_extension=1), Script('bin/morestuff.py', strip_extension=1, sbin=1), ], ) Additional keywords might be used to mark a script to be installed only on certain platforms. This could be used to install different scripts under the same name on different platforms (for example, a Mac OS X-specific script on Mac OS X, and a Tkinter script on Windows and other Unix systems). I've not determined what just the right interface would be between Script and the build_scripts and install_scripts commands; still thinking about that. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

Fred L. Drake, Jr. wrote:
[...]
The more I follow this thread the more I'm convinced that all this is beyond what distutils should care about. After all, the setup.py files are python scripts so users (packagers !) are able to put in additional logic to deal with whatever they please. Distutils already offers too much features, and instead of adding more 'default behavior' I would rather fix the existing features and make them more consistent and intuitive. Regards, Stefan PS: More often than not I find that the distutils default behavior is way too restrictive, which is one more reason for me to believe that it would be better if distutils focussed on less but does that right, instead of wanting to please everybody.

[Fred]
I guess we change the strip_extensions to a complete filespec - '*.txt', 'foo.txt', etc
I was replying to your original '--strip-extensions' idea, so it would apply to whatever files you had in mind originally <wink>.
It would seem more general to specify the full target name: scripts=[ Script('bin/dostuff.py', platforms="windows"), Script('bin/dostuff.py', target="bin/dostuff", platforms="posix"), This doesn't handle a "default" platform though (ie, what would OSX do given the above?) Maybe we need "exclude_platforms" and "include_platforms"? Script('bin/dostuff.py', include_platforms="windows"), Script('bin/dostuff.py', target="bin/dostuff", exclude_platforms="windows"), It is a real shame that setup.py has no foolproof access to the options (such as the target platform) - then we could punt the problem right back into setup.py - have it provide a different script list, possibly with explicit target names, depending on the platform. I'm wondering how close we are getting to YAGNI though.
I'm still confused by build_scripts and install_scripts in general, and still trying to understand a number of things I can't explain. But I'm getting there :) Mark

On Thursday 01 July 2004 11:56 pm, Mark Hammond wrote:
I was replying to your original '--strip-extensions' idea, so it would apply to whatever files you had in mind originally <wink>.
Ah; that was specific to scripts. So let's not muck with the plain text files. ;-)
It would seem more general to specify the full target name:
It's not clear how general we want it to be. We basically want platform policy to decide; we want to provide hints.
Something like that; perhaps "platforms" and "except_platforms".
That's exactly what I *don't* want. I want to be doing nothing conditional in the setup.py, since I really want to replace it all with metadata stored somewhere else, and have a minimum of code needed to load that metadata and pass it to distutils.core.setup().
I'm wondering how close we are getting to YAGNI though.
We're not there yet, I don't think. Other than support for sbin directories, I want all this for Zope 3. Support for installing scripts in $prefix/sbin has been requested on the list, and there's an RFE on SourceForge. I don't think it's unreasonable. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

On Jul 1, 2004, at 9:23 PM, Fred L. Drake, Jr. wrote:
Just throwing this out here.. but how about NEVER removing extensions, but also (optionally) making symlinks to the filename sans extension of scripts if the platform+filesystem supports symlinks? That would make most people happy, right? -bob

Phillip J. Eby wrote:
How would this work with static distribution files ? (Not that I really care; the above is just an academic question :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 02 2004)
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

Bob Ippolito wrote:
A .tar.gz file or a ZIP file. Anything that's not an installer and doesn't need the 'python setup.py install' dance. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 02 2004)
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

Bob Ippolito wrote:
They can, but if you unzip them on platforms that don't support symlinks you end up with empty files, so hard links would probably result in more usable results (you end up with two identical files). In any case, I'm not really sure whether stripping extensions really helps in any way. To me, removing the extension looks like a purely cosmetic operation. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 03 2004)
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

[M.-A. Lemburg] ,,,
It appears to be a religious issue for many people on OSes where extensions have no significance. They're happy to pollute file content with #! gibberish and editor turds, but are offended by extensions on executable files. So it goes -- conventions differ across platforms, and platform-natural installation is a legitimate goal no matter how foolish a given platform's conventions appear to people on other platforms.

On Saturday 03 July 2004 02:18 pm, Tim Peters wrote:
#! gibberish and editor turds
I get the "#! gibberish." What in the heck are "editor turds?" I agree with you about the characterization as a religious issue, however. On Linux/Unix platforms, it's a trivial matter to add symbolic links, and that seems to negate the extension issue, so I don't know why having scripts with extensions is so awful. Anyway, I see more and more of them cropping up in the various Linux distributions, so I think file extensions are going to come to Linux and Unix no matter how awful they seem to some.

[Bob Kimble]
I get the "#! gibberish." What in the heck are "editor turds?"
Embedded-in-the-file gibberish for the benefit of emacs or vi (Emacs local mode, tab settings, whatever). This even infects the Python PEPs, which typically end with a control character and Local Variables: mode: indented-text indent-tabs-mode: nil End: Storing metadata inside every file is at least as bizarre as maintaining a database of metadata keyed by file extension.

"Mark Hammond" <mhammond@skippinet.com.au> writes:
How about something like:
strip_extensions = {"posix": "txt py pyw", "darwin": "txt" }
I'm not sure it's relavent, but you're a bit confused here: "posix" is and os.name thing and "darwin" is a sys.platform thing (os.name is "posix" on Darwin!). Cheers, mwh -- ZAPHOD: Listen three eyes, don't try to outwierd me, I get stranger things than you free with my breakfast cereal. -- The Hitch-Hikers Guide to the Galaxy, Episode 7

Fred L. Drake, Jr. wrote:
Whatever you agree on, please use a new option for this so that you don't break existing setup code. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 15 2004)
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

On Thu, Jun 10, 2004 at 04:27:29PM -0400, Fred L. Drake, Jr. wrote:
At first I did to...
But then I read this and considered that sometimes script==application, while other times script==background_utility. I would think Windows users would like "applications" to appear in the start menu, while "behind the scenes" utility scripts live quietly and invisibly elsewhere. I don't really see "scripts in a DOS box" as a typical Windows use of Python stuff. That may be my bias as my Python on Windows experience is pretty much limited to PySol ;) Maybe we need to consider some kind of "menu" support module that conforms to freedesktop.org menu standards (GNOME & KDE are jointly working on this and I suspect, or at least hope, Linux distros will support it as well.) on *nix targets and "Start Menu" on 'doze. I would suppose that the application installer would have to somehow register where the utility scripts live (presumably the install directory or a subdir there-of). I'm fairly certain this is a non-trivial excercise, and should be dealt with independent from the file extension issue.
I think the word you're searching for is "practical" <g>. Whatever the "Windows experience" might be, Distutils has to live down to it.
I'm not sure I agree. If a developer wants to distribute a Python in a DOS box for Windows, Distutils certainly shouldn't prevent it. A simple, scriptable Python text only IRC client might be popular (but this is from a guy who has a Cygwin rxvt under ssh-agent launched in his rarely-booted XP autostart ;)
Too lazy to go look at the PEP, but isn't "supported platforms" one of the metadata fields? If not specified, it should be "any" and if .pyw's exist it should include (maybe default to?) win32. If something has .pyw's AND supports other platforms as well, then not explicitly specifying the supported platform information (which could _still_ be "any") should be an error. How other platform support is implemented in such a case should be up to the author. Trying to make Distutils smart enough to second-guess the author's intent, or the package's capabilities, would be problematic at best. OTOH, a boolean GUI tag for scripts might be beneficial for cross-platform menu integration, so ... I'll stand firm on the "maybe" side of the question. mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/

Did we reach any conclusions regarding script installation? I think there are still some issues. I *think* we agreed that stripping a .py extension for scripts on Unix is acceptable, but it's not clear that any Unix-oriented users other than myself were involved in the discussion. I don't think we can simply rip off .py extensions on Unix, since that changes the set of installed names for packages that support older versions of Python/distutils; there probably needs to be some explicit gesture that this is desired in the call to distutils.core.setup() (or maybe just in setup.cfg). I asked about silently not installing .pyw scripts on Unix, but I've not seen any responses on that issue. I'd like to have a better idea of how much agreement there might be before starting to work on a patch. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

On Monday 14 June 2004 05:28 pm, Fred L. Drake, Jr. wrote:
I'm a Linux guy myself, and I prefer the .py extensions. I figure you can always make a symbolic link to a filename without the extension if you like. All my Python scripts have .py extensions. Of course, all my bash scripts have .sh extensions, too. I don't know what the norm is, but that's my 2 cents. Regards, .... Bob

On 15-jun-04, at 3:59, Bob Kimble wrote:
The norm is that scripts don't have extensions, that's why you use 'zgrep' and not 'zgrep.sh' ;). The implementation language is not interesting for the user of your script. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173

On 14-jun-04, at 23:28, Fred L. Drake, Jr. wrote:
I'm fine with that (as a unix- and mac-oriented person).
Please don't, unless MacOS X is treated differently than other unices. There is a minor difference between GUI and non-GUI scripts on OSX (due to a misfeature of the OS). Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173

On Tuesday 15 June 2004 01:07 am, Ronald Oussoren wrote:
--sigh-- So as I understand it, you'd need an extension to be left on for .pyw scripts, but could tolerate removal of extensions for other scripts. This is a distinct case from other Unixes and from Windows. I have a patch that will strip extensions for POSIX platforms other than Darwin (including Mac OS X), only if "build_scripts --strip-extensions" is used. Given the special cases and another issue related to legacy support, I'm not going to apply the patch. The other issue is one of supporting scripts that want to keep their extension (because they need to be command-line compatible with how they were previously installed) at the same time as providing scripts with extensions stripped by default. My own expectation is that I'd want to ship a setup.cfg file that set this by default, but I'd want to exclude specific scripts. This indicates that the simple model of a boolean flag isn't sufficient. I've posted my patch with a brief summary of these issues in the Python patch tracker on SourceForge: http://www.python.org/sf/976869 -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

On 21-jun-04, at 18:54, Fred L. Drake, Jr. wrote:
I really have to start reading my own mails some time... What I tried to say is "please don't ignore scripts with a .pyw extension in the scripts argument of setup". With MacOS X it all depends on how you look at things :-). If you want to start scripts by double-clicking on them they should have an extension (either .py or .pyw), if you're a unix-head that starts scripts from the shell the extension is annoying. IMHO the only correct way for installing GUI programs on MacOS X is creating an application bundle (which is a directory with a special structure). But that's just one opinion, and not necessarily relevant for this discussion. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173

On Jun 21, 2004, at 12:54 PM, Fred L. Drake, Jr. wrote:
Please don't make this special exception for sys.platform=='darwin'. - You can't browse to /usr/local/bin from Finder, anyway - It's almost impossible to write a useful GUI application without wrapping it in an application bundle in OS X -bob

Tim just pointed this thread out to me, so I thought I would try and keep it alive :) [Fred wrote]
How about something like: strip_extensions = {"posix": "txt py pyw", "darwin": "txt" } Where strip_extensions is a dictionary, keyed by the platform name (either sys.platform or os.name - whatever makes sense. The value is the list of extensions that should be stripped. This allows README.FIRST etc to remain intact, and allows fine control over what platforms it is applied to. The downside is that it can't really be spelt on the command-line. However, I argue that anyone who needs such fine grained control will have somewhere more suitable to specify it anyway. Would that make sense? Mark.

On Thursday 01 July 2004 09:59 pm, Mark Hammond wrote:
Tim just pointed this thread out to me, so I thought I would try and keep it alive :)
Good timing! I'be been thinking about this just this evening.
So how do you spell "I want the extension stripped from this one file on one platform, and that's it."? I'm also confused by your inclusion of "txt"; does this apply to all file copies, just scripts, or some magically determined set of file copies? I think the answer is that we want something similar to the Extension class for scripts, to give us a "bag" for script-specific options. I don't see any reason to extend extension-stripping beyond scripts. If we have a Script class that parallels Extension, that could encapsute some of the script-specific options. Listing scripts with just paths instead of Script instances would cause the current behavior to be used (which should also be what's used for just Script('path/scriptname.py')). That would allow something like this in setup.py: from distutils.core import setup, Script setup(name='Some Python Utilities', packages=['mytools'], scripts=[Script('bin/dostuff.py', strip_extension=1), Script('bin/morestuff.py', strip_extension=1, sbin=1), ], ) Additional keywords might be used to mark a script to be installed only on certain platforms. This could be used to install different scripts under the same name on different platforms (for example, a Mac OS X-specific script on Mac OS X, and a Tkinter script on Windows and other Unix systems). I've not determined what just the right interface would be between Script and the build_scripts and install_scripts commands; still thinking about that. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

Fred L. Drake, Jr. wrote:
[...]
The more I follow this thread the more I'm convinced that all this is beyond what distutils should care about. After all, the setup.py files are python scripts so users (packagers !) are able to put in additional logic to deal with whatever they please. Distutils already offers too much features, and instead of adding more 'default behavior' I would rather fix the existing features and make them more consistent and intuitive. Regards, Stefan PS: More often than not I find that the distutils default behavior is way too restrictive, which is one more reason for me to believe that it would be better if distutils focussed on less but does that right, instead of wanting to please everybody.

[Fred]
I guess we change the strip_extensions to a complete filespec - '*.txt', 'foo.txt', etc
I was replying to your original '--strip-extensions' idea, so it would apply to whatever files you had in mind originally <wink>.
It would seem more general to specify the full target name: scripts=[ Script('bin/dostuff.py', platforms="windows"), Script('bin/dostuff.py', target="bin/dostuff", platforms="posix"), This doesn't handle a "default" platform though (ie, what would OSX do given the above?) Maybe we need "exclude_platforms" and "include_platforms"? Script('bin/dostuff.py', include_platforms="windows"), Script('bin/dostuff.py', target="bin/dostuff", exclude_platforms="windows"), It is a real shame that setup.py has no foolproof access to the options (such as the target platform) - then we could punt the problem right back into setup.py - have it provide a different script list, possibly with explicit target names, depending on the platform. I'm wondering how close we are getting to YAGNI though.
I'm still confused by build_scripts and install_scripts in general, and still trying to understand a number of things I can't explain. But I'm getting there :) Mark

On Thursday 01 July 2004 11:56 pm, Mark Hammond wrote:
I was replying to your original '--strip-extensions' idea, so it would apply to whatever files you had in mind originally <wink>.
Ah; that was specific to scripts. So let's not muck with the plain text files. ;-)
It would seem more general to specify the full target name:
It's not clear how general we want it to be. We basically want platform policy to decide; we want to provide hints.
Something like that; perhaps "platforms" and "except_platforms".
That's exactly what I *don't* want. I want to be doing nothing conditional in the setup.py, since I really want to replace it all with metadata stored somewhere else, and have a minimum of code needed to load that metadata and pass it to distutils.core.setup().
I'm wondering how close we are getting to YAGNI though.
We're not there yet, I don't think. Other than support for sbin directories, I want all this for Zope 3. Support for installing scripts in $prefix/sbin has been requested on the list, and there's an RFE on SourceForge. I don't think it's unreasonable. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

On Jul 1, 2004, at 9:23 PM, Fred L. Drake, Jr. wrote:
Just throwing this out here.. but how about NEVER removing extensions, but also (optionally) making symlinks to the filename sans extension of scripts if the platform+filesystem supports symlinks? That would make most people happy, right? -bob

Phillip J. Eby wrote:
How would this work with static distribution files ? (Not that I really care; the above is just an academic question :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 02 2004)
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

Bob Ippolito wrote:
A .tar.gz file or a ZIP file. Anything that's not an installer and doesn't need the 'python setup.py install' dance. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 02 2004)
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

Bob Ippolito wrote:
They can, but if you unzip them on platforms that don't support symlinks you end up with empty files, so hard links would probably result in more usable results (you end up with two identical files). In any case, I'm not really sure whether stripping extensions really helps in any way. To me, removing the extension looks like a purely cosmetic operation. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 03 2004)
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

[M.-A. Lemburg] ,,,
It appears to be a religious issue for many people on OSes where extensions have no significance. They're happy to pollute file content with #! gibberish and editor turds, but are offended by extensions on executable files. So it goes -- conventions differ across platforms, and platform-natural installation is a legitimate goal no matter how foolish a given platform's conventions appear to people on other platforms.

On Saturday 03 July 2004 02:18 pm, Tim Peters wrote:
#! gibberish and editor turds
I get the "#! gibberish." What in the heck are "editor turds?" I agree with you about the characterization as a religious issue, however. On Linux/Unix platforms, it's a trivial matter to add symbolic links, and that seems to negate the extension issue, so I don't know why having scripts with extensions is so awful. Anyway, I see more and more of them cropping up in the various Linux distributions, so I think file extensions are going to come to Linux and Unix no matter how awful they seem to some.

[Bob Kimble]
I get the "#! gibberish." What in the heck are "editor turds?"
Embedded-in-the-file gibberish for the benefit of emacs or vi (Emacs local mode, tab settings, whatever). This even infects the Python PEPs, which typically end with a control character and Local Variables: mode: indented-text indent-tabs-mode: nil End: Storing metadata inside every file is at least as bizarre as maintaining a database of metadata keyed by file extension.

"Mark Hammond" <mhammond@skippinet.com.au> writes:
How about something like:
strip_extensions = {"posix": "txt py pyw", "darwin": "txt" }
I'm not sure it's relavent, but you're a bit confused here: "posix" is and os.name thing and "darwin" is a sys.platform thing (os.name is "posix" on Darwin!). Cheers, mwh -- ZAPHOD: Listen three eyes, don't try to outwierd me, I get stranger things than you free with my breakfast cereal. -- The Hitch-Hikers Guide to the Galaxy, Episode 7

Fred L. Drake, Jr. wrote:
Whatever you agree on, please use a new option for this so that you don't break existing setup code. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 15 2004)
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
participants (11)
-
Bob Ippolito
-
Bob Kimble
-
Fred L. Drake, Jr.
-
M.-A. Lemburg
-
Mark Hammond
-
Mark W. Alexander
-
Michael Hudson
-
Phillip J. Eby
-
Ronald Oussoren
-
Stefan Seefeld
-
Tim Peters