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

Allow manual override of shebang executable of installed scripts #3842

Closed
chadrik opened this issue Jul 13, 2016 · 2 comments
Closed

Allow manual override of shebang executable of installed scripts #3842

chadrik opened this issue Jul 13, 2016 · 2 comments
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@chadrik
Copy link

chadrik commented Jul 13, 2016

  • Pip version: 8.1.2
  • Python version: 2.7.x
  • Operating System: Fedora19 and OSX 10.10.x

I'm trying to find a way to manually set the shebang executable of scripts installed from wheels.

Our company must deploy and use many versions of python -- even different "micro" releases (e.g. 2.7.9 vs 2.7.10) -- across multiple OSes with a very large set of packages installed from PyPI and from source. Adding a single new requirement can take a lot of time to redeploy for all of these targets. Baking sys.executable into the shebang ties a deployment to a particular micro release of python on a particular OS, even when packages could easily be reused across micro releases, and even across OS in the case of pure python packages.

To reduce the number of deployments, and thereby cut down on our build time, I'd like to be able to set the shebang of bin scripts to #!/usr/bin/env python, so that the active version of python will be found on any of our Linux and OSX flavors.

I believe this should be a matter of getting an option from pip install through to pip.wheel.move_wheel_files() in order to do the following:

    maker = ScriptMaker(None, scheme['scripts'])
    maker.executable = executable_override

Currently, we build wheels of all our requirements and cache them locally, so if the problem can be solved during the building of wheels, that would be acceptable as well, though ultimately less generally useful.

Thanks!

@dholth
Copy link
Member

dholth commented Jul 13, 2016

The entry_points scripts are only written after the wheel is installed.

If you want to make a standalone tool it would be very easy to excerpt the part of pip.wheel that calls ScriptMaker, and use a normal non-vendored copy of distlib, to regenerate the scripts for any installed package, at any time after it has been installed.

@dstufft
Copy link
Member

dstufft commented Mar 30, 2017

Closing this, I don't believe this use case is sufficiently general to include into pip, in particular since you can add this yourself by regenerating the scripts as mentioned by Daniel.

@dstufft dstufft closed this as completed Mar 30, 2017
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

No branches or pull requests

3 participants