Re: [Distutils] Installing scripts
On Thursday 10 June 2004 04:06 pm, Tim Peters wrote:
"scripts" in the sense we're using here are Python files, and in Windows they're only useful from "a DOS box". It's not useful to double-click on them, it's not useful to have Start menu entries(*) for them, and it would
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.
For cross-platform *development*, all Python files should have a .py extension. On Windows the extension drives editors and printers too (not just the "open" action in a DOS box window).
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.
I'm happy enough with where they end up on Windows now, and delighted there are no Start menu entries for them, it's just the lack of the natural (on Windows) .py extension that creates needless pain (on Windows).
Again, agreed. We just need to make sure the .py is there on Windows and not on installed scripts on Unix.
(*) The only thing useful to have in the Start menu is a program that supplies its own GUI, or a program that has no UI. On Windows, that's what the .pyw extension is for (brings up Python without "a DOS box", so there's no UI at all unless the script supplies its own UI; for example, IDLE supplies its own UI, via Tk).
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:
On Thursday 10 June 2004 04:06 pm, Tim Peters wrote:
"scripts" in the sense we're using here are Python files, and in Windows they're only useful from "a DOS box". It's not useful to double-click on them, it's not useful to have Start menu entries(*) for them, and it would
Agreed.
At first I did to...
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.
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.
For cross-platform *development*, all Python files should have a .py extension. On Windows the extension drives editors and printers too (not just the "open" action in a DOS box window).
I'm actually pretty OK with this. It's slightly distasteful, but survivable.
I think the word you're searching for is "practical" <g>. Whatever the "Windows experience" might be, Distutils has to live down to it.
(*) The only thing useful to have in the Start menu is a program that supplies its own GUI, or a program that has no UI. On Windows, that's what the .pyw extension is for (brings up Python without "a DOS box", so there's no UI at all unless the script supplies its own UI; for example, IDLE supplies its own UI, via Tk).
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 ;)
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?
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 *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'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 14-jun-04, at 23:28, Fred L. Drake, Jr. wrote:
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'm fine with that (as a unix- and mac-oriented person).
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.
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 15-jun-04, at 3:59, Bob Kimble wrote:
On Monday 14 June 2004 05:28 pm, Fred L. Drake, Jr. wrote:
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'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.
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
Fred L. Drake, Jr. wrote:
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.
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)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
On Tuesday 15 June 2004 01:07 am, Ronald Oussoren wrote:
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).
--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:
On Tuesday 15 June 2004 01:07 am, Ronald Oussoren wrote:
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).
--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 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:
On Tuesday 15 June 2004 01:07 am, Ronald Oussoren wrote:
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).
--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.
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
Fred L. Drake, Jr. wrote:
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.
[...]
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).
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.
Tim just pointed this thread out to me, so I thought I would try and keep it alive :) [Fred 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.
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.
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.
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]
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.
So how do you spell "I want the extension stripped from this one file on one platform, and that's it."?
I guess we change the strip_extensions to a complete filespec - '*.txt', 'foo.txt', etc
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 was replying to your original '--strip-extensions' idea, so it would apply to whatever files you had in mind originally <wink>.
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).
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've not determined what just the right interface would be between Script and the build_scripts and install_scripts commands; still thinking about that.
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.
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"?
Something like that; perhaps "platforms" and "except_platforms".
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.
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>
"Mark Hammond"
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
On Jul 1, 2004, at 9:23 PM, Fred L. Drake, Jr. wrote:
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. ;-)
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
On Friday 02 July 2004 01:18 pm, Bob Ippolito wrote:
On Jul 1, 2004, at 9:23 PM, Fred L. Drake, Jr. wrote:
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. ;-)
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
That is exactly my preference. Maybe it's a "bob" thing. :-)
At 10:18 AM 7/2/04 -0700, Bob Ippolito 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?
+1. Sounds good to me.
Phillip J. Eby wrote:
At 10:18 AM 7/2/04 -0700, Bob Ippolito 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?
+1. Sounds good to me.
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)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
On Jul 2, 2004, at 1:23 PM, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 10:18 AM 7/2/04 -0700, Bob Ippolito 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? +1. Sounds good to me.
How would this work with static distribution files ?
(Not that I really care; the above is just an academic question :-)
What is a static distribution file? -bob
Bob Ippolito wrote:
On Jul 2, 2004, at 1:23 PM, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 10:18 AM 7/2/04 -0700, Bob Ippolito 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?
+1. Sounds good to me.
How would this work with static distribution files ?
(Not that I really care; the above is just an academic question :-)
What is a static distribution file?
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)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
On Jul 2, 2004, at 1:44 PM, M.-A. Lemburg wrote:
Bob Ippolito wrote:
On Jul 2, 2004, at 1:23 PM, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 10:18 AM 7/2/04 -0700, Bob Ippolito 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?
+1. Sounds good to me.
How would this work with static distribution files ?
(Not that I really care; the above is just an academic question :-) What is a static distribution file?
A .tar.gz file or a ZIP file. Anything that's not an installer and doesn't need the 'python setup.py install' dance.
Can't .tar.gz files contain symlinks? Would you even use zip on a platform that supported symlinks? -bob
Bob Ippolito wrote:
On Jul 2, 2004, at 1:44 PM, M.-A. Lemburg wrote:
Bob Ippolito wrote:
On Jul 2, 2004, at 1:23 PM, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 10:18 AM 7/2/04 -0700, Bob Ippolito 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?
+1. Sounds good to me.
How would this work with static distribution files ?
(Not that I really care; the above is just an academic question :-)
What is a static distribution file?
A .tar.gz file or a ZIP file. Anything that's not an installer and doesn't need the 'python setup.py install' dance.
Can't .tar.gz files contain symlinks? Would you even use zip on a platform that supported symlinks?
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)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
[M.-A. Lemburg] ,,,
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.
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.
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