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
Loosen restrictions on shebang. #34
Conversation
This comment has been minimized.
This comment has been minimized.
What do you think about keeping |
@warsaw I thought about that too, but ultimately felt like it would be confusing... say someone didn't want |
98ee918
to
987b594
Compare
True, but OTOH if they just want the defaults (which should be the most common case, right?) they'll have to use I guess it's a 6 vs 1/2 dozen thing, so as long as the change is well communicated and the documentation is up to date, I don't have a strong opinion either way. |
docs/history.rst
Outdated
always including the `-s <https://docs.python.org/3/using/cmdline.html#cmdoption-s>`_ and | ||
dependency, the performance implications are mitigated by limiting the length of ``sys.path``. | ||
Internally, we always including the | ||
`-s <https://docs.python.org/3/using/cmdline.html#cmdoption-s>`_ and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still true then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Notice that I added "internally we..." 😉
Yah, I actually feel like the behavior is more obvious now, since it's non-typical for folks to be using those flags. |
Re: Internally - will an outside consumer know what that means? Maybe just suggest that for better isolation from the system's and user's Python environment, these flags can be used? Re: default use of the flags - I'm not sure whether it's non-typical because folks don't think about it, or whether they really do no want isolation in general. None of this is a blocker for me though. Just thoughts about usability. |
This commit loosens shiv's requirements when constructing a shebang line: rather than enforcing that the target interpreter must exist, we simply accept what the user provides. We no longer append `-sE` to the shebang as these arguments can be provided to the value given to the `--python` argument. Shiv will now exit(1) if the resulting shebang would exceed the BIN_PRM restrictions present on most unix-y OSes. Fixes #17
@warsaw I updated the wording in the history doc to be more clear, but rather than try and tack on |
987b594
to
8208b54
Compare
I did not actually know about |
This commit loosens shiv's requirements when constructing a shebang
line: rather than enforcing that the target interpreter must exist, we
simply accept what the user provides.
We no longer append
-sE
to the shebang as these arguments can beprovided to the value given to the
--python
argument.Shiv will now exit(1) if the resulting shebang would exceed the BIN_PRM
restrictions present on most unix-y OSes.
Fixes #17
After merging I'll cut a new release (0.0.26)