Skip to content
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

Support for interpreter argument in console_scripts. #204

Closed
ghost opened this issue May 8, 2014 · 2 comments
Closed

Support for interpreter argument in console_scripts. #204

ghost opened this issue May 8, 2014 · 2 comments

Comments

@ghost
Copy link

ghost commented May 8, 2014

Originally reported by: nilp0inter (Bitbucket: nilp0inter, GitHub: nilp0inter)


HI

Is there any way of adding custom arguments to the shebang of the console_scripts generated?

If it's not possible, I'd like to propose the addition of such feature.

We are experiencing problems using some libraries (like wsgiref) that are doing "assert" internally. It is impossible to desactive them unless you use the "-O" parameter in the interpreter.

Thank you.


@ghost
Copy link
Author

ghost commented May 8, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


I don't believe there is currently support for this. One of the main reasons for console_scripts is to abstract that concept to other platforms that don't support shebang scripts (primarily Windows at this point). Any solution is going to have to consider the portability implications.

@pganssle pganssle added the Needs Triage Issues that need to be evaluated for severity and status. label Oct 19, 2018
@abravalheri
Copy link
Contributor

Since the Python package ecosystem has moved towards standardisation in the last years, I think it would be better to discuss this proposals in https://discuss.python.org/c/packaging.

It would probably need a PEP, because it requires changing existing standards (https://packaging.python.org/en/latest/specifications/entry-points/).

I think the best would be closing this issue in the context of setuptools, for the time being.
If the community reaches consensus in the packaging forum I would be glad to continue with this conversation in a future proof of concept or PR 😄

@abravalheri abravalheri removed the Needs Triage Issues that need to be evaluated for severity and status. label Jan 4, 2022
jaraco pushed a commit that referenced this issue Aug 2, 2024
This was added back in the day to make mingw use the same CRT as CPython
(https://bugs.python.org/issue870382), but at least with newer mingw-w64 and
ucrt switching the CRT at "runtime" isn't supported anymore. To build a
compatible extension you have to use a ucrt mingw-w64 build, so things match
up and link against the same CRT.

CPython 3.5+ uses ucrt (see https://wiki.python.org/moin/WindowsCompilers), so
anything besides that is no longer relevant, which only leaves vcruntime140.

Since it's not clear what linking against vcruntime140 solves, and there have
been reports of it needing to be patched out:

* #4101
* pypa/distutils#204 (comment)

let's just make it return nothing. Keep get_msvcr() around for now to avoid breaking
code which patched it.

Fixes #204
jaraco pushed a commit that referenced this issue Aug 2, 2024
This was added back in the day to make mingw use the same CRT as CPython
(https://bugs.python.org/issue870382), but at least with newer mingw-w64 and
ucrt switching the CRT at "runtime" isn't supported anymore. To build a
compatible extension you have to use a ucrt mingw-w64 build, so things match
up and link against the same CRT.

CPython 3.5+ uses ucrt (see https://wiki.python.org/moin/WindowsCompilers), so
anything besides that is no longer relevant, which only leaves vcruntime140.

Since it's not clear what linking against vcruntime140 solves, and there have
been reports of it needing to be patched out:

* #4101
* pypa/distutils#204 (comment)

let's just make it return nothing. Keep get_msvcr() around for now to avoid breaking
code which patched it.

Fixes #204
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants