Issue 870479: Scripts need platform-dependent handling (original) (raw)

Issue870479

Created on 2004-01-04 19:00 by ceder, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (22)
msg19537 - (view)	Author: Per Cederqvist (ceder)	Date: 2004-01-04 19:00
When a script is installed on Unix, it should be named something like "mailman-discard", with no extension. When it is installed on Windows, it should be named "mailman-discard.py", so that it is associated with Python. I think that "scripts" should be smart enough to handle this. My suggestion is that "scripts" should be set to a list of the scripts, including the extension, and that distutils will remove the extension when it installs programs on platforms where this is true: os.name == 'posix' It is possible to override the install_scripts class to get this behaviour, but if you want to make a binary distribution you also have to override bdist_wininst, et c, since the install_scripts class is used on the host system while building a directory tree that will later be installed on the target system. See this example script: http://cvs.lysator.liu.se/viewcvs/viewcvs.cgi/mailman-discard/setup.py?rev=1.2&cvsroot=mailman-discard&content-type=text/vnd.viewcvs-markup Peter Åstrand also suggests that on Windows, you should create a command file named "mailman-discard.cmd" and put it in the same directory as the "mailman-discard.py" file. It should contain a single line: start %~dp0\mailman-discard.py That way, you will be able to start the script from a dos shell, and not just by double-clicking it in a file browser. It would be nice if Distutils created this file automatically when installing on the win32 platform.
msg19538 - (view)	Author: Paul Moore (paul.moore) *	Date: 2004-01-05 16:25
Logged In: YES user_id=113328 Having a ".cmd" file isn't a good idea. For a start, it isn't Windows 9x compatible (and %~dp0 isn't available in command.com). Also, you need to include a way of passing any command line arguments on to the script. And finally, "start" probably isn't right. This will run the command in a new console window, rather than in the existing console. A XXX.cmd file which just does @%~dp0\XXX.py %* is better, but I still don't think it's needed. Just adding ".py" to PATHEXT (which is something the user can do if they want, at the same time they add the Python scripts directory to their PATH) is enough, at least on NT/2000/XP.
msg19539 - (view)	Author: Per Cederqvist (ceder)	Date: 2004-01-05 18:44
Logged In: YES user_id=129207 You have convinced me that the ".cmd" file was a bad idea, so let's forget I ever mentioned it. I still think that the extension should be removed on POSIX platforms, however. However, if you have "foo.py" and "foo.sh" they would both end up as "foo"; this should produce a diagnostic.
msg19540 - (view)	Author: Mark Hammond (mhammond) *	Date: 2004-07-02 00:41
Logged In: YES user_id=14198 The obvious issue is that we can't change the semantics for packages already out there. Existing package maintainers will not want this change made for them automatically, and it is not clear that this is the desirable default behaviour anyway. Therefore, this isn't going to be considered a 'bug'. I think what you are asking for is a new feature - a way to give distutils the behaviour you desire, but leaving the default semantics alone. I suggest you close this bug as "wont fix", and add a new feature request. After that, try and get some support for your idea from someone willing or able to submit a patch.
msg19541 - (view)	Author: Tim Peters (tim.peters) *	Date: 2004-07-02 01:02
Logged In: YES user_id=31435 Note this was an active topic on distutils-sig last week. Assigned to Fred in hopes that he can summarize current thinking as a comment here.
msg19542 - (view)	Author: Mark Hammond (mhammond) *	Date: 2004-07-02 01:52
Logged In: YES user_id=14198 Thanks Tim - I found the thread - interesting, and funnily enough covers the same issues! I also note www.python.org/sf/976869 which is where Fred has made a patch. My summary: nothing should be done implicitly. Whatever is done must be explicitly specified by the packager. However, no one is sure exactly how to spell it yet.
msg19543 - (view)	Author: Tim Peters (tim.peters) *	Date: 2004-07-02 01:58
Logged In: YES user_id=31435 Yup, I agree, Mark. Fred too. This has hit heated temperatures at times in the Zope world, where Windows users need .py extensions for sane script life under cmd.exe, but somewhat over half of Unixish geeks go on like they're being raped if an informative extension assults their prissy eyeballs .
msg19544 - (view)	Author: Fred Drake (fdrake)	Date: 2004-07-02 03:30
Logged In: YES user_id=3066 Here's an idea about how to spell this: http://mail.python.org/pipermail/distutils-sig/2004-July/004073.html
msg55169 - (view)	Author: Fred Drake (fdrake)	Date: 2007-08-23 18:08
Removing the assignment to me, since I'm not going to resolve the fundamental disagreements about what "the right thing" is. Someone else can argue with the wrong-headed.
msg82018 - (view)	Author: Daniel Diniz (ajaksu2) *	Date: 2009-02-14 12:08
Has a decision been made on this? What's the current behavior on Windows?
msg82030 - (view)	Author: Tarek Ziadé (tarek) *	Date: 2009-02-14 12:23
What do you think about the way setuptools handles it ? I'd be in favor of integrating setuptools wrapping mechanism in distutils. (not the entry point part, just the way it generates .exe under windows and executable script under Linux) see http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation
msg82035 - (view)	Author: Paul Moore (paul.moore) *	Date: 2009-02-14 12:42
In principle I don't have a problem with the automatic generation of an EXE (I assume it generates a shell script with no extension on Unix?) but it should be done in such a way that the EXE is version-independent. This is necessary to ensure that pure-python packages, when made into bdist_wininst installers, continue to be version-independent. (At the moment, distutils generates version-dependent bdist_wininst packages *only* for C extensions. Setuptools generates version-dependent installers all the time, which is a pain). This may mean that a reimplementation is required, rather than copying the setuptools code.
msg82147 - (view)	Author: Tarek Ziadé (tarek) *	Date: 2009-02-15 09:53
more discussion here : http://mail.python.org/pipermail/distutils-sig/2009-February/010980.html
msg82148 - (view)	Author: Tarek Ziadé (tarek) *	Date: 2009-02-15 09:54
> I assume it generates a shell script with no extension on Unix? Yes
msg102907 - (view)	Author: Éric Araujo (eric.araujo) *	Date: 2010-04-11 22:44
This bug supersedes #1004696.
msg112250 - (view)	Author: Éric Araujo (eric.araujo) *	Date: 2010-08-01 01:26
As a first step, do you agree that newlines have to be translated?
msg112286 - (view)	Author: Paul Moore (paul.moore) *	Date: 2010-08-01 08:13
I don't think that they do, any more than for any .py script. (I assume you're talking about in the .py script). Generated scripts on Unix can be whatever the code wants, and on Windows I thought the idea of generated scripts had been dropped.
msg112312 - (view)	Author: Éric Araujo (eric.araujo) *	Date: 2010-08-01 11:32
Sorry, I was unclear. What I meant is: Do you (Tarek and platform experts) agree that scripts (in setup(scripts=...), not generated) need to have platform-specific EOLs?
msg112321 - (view)	Author: Paul Moore (paul.moore) *	Date: 2010-08-01 12:38
Thanks for clarifying. No, I don't agree. Barring fancy "if os.platform" games in setup.py, scripts will be platform-independent Python code. From "Distributing Python Modules" section 2.5, "Scripts are files containing Python source code", and as such, should follow the normal rules for Python code (from the language reference section 2.1.2, "In source files, any of the standard platform line termination sequences can be used"). On Windows, that's the end of the story. I believe Unix is the same, although it's possible that the #! line processing may rely on \n line endings - I can't comment on this. The question here is not about the scripts themselves, but rather about how they are installed. My view is very simple: - Scripts should be named with a .py extension - On Windows, they should be installed with a .py extension - On Unix, I'd be happy with a .py extension, but some Unix users hate extensions on commands, and dispute this. (Hence either renaming or wrapper suggestions :-)). - There is some debate as to whether "wrappers" should be generated (shell script on Unix, exe on Windows). I'd prefer not, some people like them. Ideally, it should be user-configurable, but that's going to be messy in the case of bdist_xxx installers.
msg117683 - (view)	Author: Éric Araujo (eric.araujo) *	Date: 2010-09-30 01:10
> it's possible that the #! line processing may rely on \n line endings It does. Python on POSIX can import modules with CLRF, but the shebang machinery can’t parse the first line to get the interpreter to run. Does anyone object about changing that? Re: generating scripts, I’m moving from -0.5 to +0. I think this requires a bit of summing up previous discussions (bug reports, emails, pros and cons here and there) so I won’t get to it for weeks or months, but someone else is free to do it. I suggest opening a new feature request and linking to it from here.
msg117726 - (view)	Author: Fred Drake (fdrake)	Date: 2010-09-30 11:56
As noted in issue 976869, I'm very much in the camp of entry-point based generated scripts, which should clearly use the right line endings for the host platform. Hacking around with the file copy just doesn't make sense moving forward.
msg138935 - (view)	Author: Éric Araujo (eric.araujo) *	Date: 2011-06-24 12:23
All right, we’re going to follow setuptools’ lead and generate platform-appropriate script or binary files from callables. See the superseder bug report to follow the work that will be done during this summer’s GSoC.