-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Environment activation on the shebang line? #2238
Comments
you should do |
Right, I get that I can manually determine the venv path and just put that path into my script. I'm asking if it'd be compelling to do this programmatically from the shebang line itself. As pipenv "owns" the translation of a project path to a venv path, it'd be more portable and more future-proof if a script knows how to ask pipenv every time. I'd like to be able to clone a Github repo into I can't think of how to do this without additional support from pipenv that doesn't involve a relatively sophisticated wrapper script that invokes pipenv --venv from the (I realize shebang lines are specific to certain shells. It's just the first thing that occurred to me because it gives pipenv the opportunity to pick the Python interpreter.) |
I just encountered issues with setting up tool scripts to just run within
Is there a way to do that? |
I think this issue is still outstanding (despite being marked as closed). Presumably the path referred to by @kennethreitz is not suitable for e.g. being checked in to a git repo? A generic way to launch a tool without setting up an environment first would be great. (Imagine if standard unix tools required environment setup before you ran them...) |
This is an issue, but not one Pipenv wishes to get into. Pipenv is a tool to manage environments, not to help package and redistribute your application. You should use other tools for that purpose. |
I think I agree - why can't your setup script install your virtual environment in a specific location everytime? |
It can, but I think this feature is useful when you're specifically not packaging or distributing an application, just trying to run an arbitrary script with an arbitrary environment. What do you do when you just want a script in your home running against a specific environment? Copy and paste the magic path into the #! line? The proposed solution would be nicer IMHO. |
The proposed solution is nicer, but impossible, AFAICT. I would be happy to be proven wrong. |
This should do it (works for me):
|
@cfzlp |
You're right. I didn't know this, but on Linux execve behaves differently and passes 'pipenv run python' as a single argument to http://mail-index.netbsd.org/netbsd-users/2008/11/09/msg002388.html |
Using the following one-liner as a wrapper is a nice workaround: #!/bin/sh
pipenv run $(basename $0) "$@" You can - for instance - call it #!/usr/bin/env /somepath/bash
which python # should show a path inside your pipenv This works around both Linux shebang arguments limitation and BSD's/OSX' limitation on non-binary shebang interpreters. Note: this wrapper or its symlink cannot appear in the |
you should quote #!/bin/sh
exec pipenv run "$(basename "$0")" "$@" not sure if all shells can handle nested quotes, so maybe even: #!/bin/sh
script=$(basename "$0")
exec pipenv run "$script" "$@" |
Slightly changing what @cfzlp suggested works for me on Debian (coreutils version 8.30):
|
@fernandezcuesta Unfortunately |
I made a tiny package that allows you to do this with:
See pipenv-shebang |
FWIW with Nix you can just do e.g.
|
@laktak: portable version is |
Thanks for the input, I've updated it. |
I was inspired to ask about specifying the project dir as a command line arg (#2237) while thinking about invoking tools in their own venvs. At some point I realized that I could use a venv's
python
to invoke a tool and it would just work without having to activate anything in my shell. I assume this is entirely by design.With pipenv managing venv paths, it might be compelling to be able to invoke a tool via pipenv, where pipenv would determine the venv from the tool's path and not the current working directory. Perhaps pipenv could be the tool runner on the shebang line, something like this:
Is this compelling? Or am I missing a different best practice for organizing tools with their own venvs? Or do people just prefer to not do this and use global site-packages for everything they intend to run on their own machines? (And if I'm dev'ing my own tools, I would do actual releases into my everyday-carry environment, and use venvs just for development?)
The text was updated successfully, but these errors were encountered: