New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scripts need platform-dependent handling #39761
Comments
When a script is installed on Unix, it should be named My suggestion is that "scripts" should be set to a list
It is possible to override the install_scripts class to Peter Åstrand also suggests that on Windows, you should start %~dp0\mailman-discard.py That way, you will be able to start the script from a |
Logged In: YES Having a ".cmd" file isn't a good idea. For a start, it isn't A XXX.cmd file which just does @%~dp0\XXX.py %* is |
Logged In: YES You have convinced me that the ".cmd" file was a bad idea, I still think that the extension should be removed on POSIX |
Logged In: YES The obvious issue is that we can't change the semantics for I think what you are asking for is a new feature - a way to |
Logged In: YES Note this was an active topic on distutils-sig last week. |
Logged In: YES Thanks Tim - I found the thread - interesting, and funnily My summary: nothing should be done implicitly. Whatever is |
Logged In: YES Yup, I agree, Mark. Fred too. This has hit heated |
Logged In: YES Here's an idea about how to spell this: http://mail.python.org/pipermail/distutils-sig/2004-July/004073.html |
Removing the assignment to me, since I'm not going to resolve the |
Has a decision been made on this? What's the current behavior on Windows? |
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 see |
In principle I don't have a problem with the automatic generation of an This may mean that a reimplementation is required, rather than copying |
more discussion here : |
Yes |
This bug supersedes bpo-1004696. |
As a first step, do you agree that newlines have to be translated? |
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. |
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? |
Thanks for clarifying. No, I don't agree. Barring fancy "if os.platform" games in setup.py, On Windows, that's the end of the story. I believe Unix is the same, The question here is not about the scripts themselves, but rather
|
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. |
As noted in bpo-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. |
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. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: