-
-
Notifications
You must be signed in to change notification settings - Fork 402
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
Question regarding prompt changing #135
Comments
In pyenv-virtualenv prior to v20151222, there were some known issues related to management of To solve all those issues intrinsically, pyenv-virtualenv stopped using https://github.com/yyuu/pyenv-virtualenv/blob/v20151222/bin/pyenv-sh-activate#L221 Now you can see what virtual environment (or a version) is activated from the output of Any contributions are always welcomed. We need more hands and eyes to improve things, especially for documentation since I am pretty bad at documentation 😛 |
I'm still not sure if I understand fully. (; So, you won't remove the code for changing the prompt entirely (that's how the message read to me!), but the prompt change won't be the default anymore and users will have to (re)enable it via their shell (with the Is that it? And will that affect both the 'activate/deactivate' messages and the display of the virtualenv's name? (Meaning: does the variable cover both, or is it possible to only get the name displayed and not the activate/deactivate messages?) Regarding the documentation: yeah, I'd especially like for it (any documentation, really!) to be as beginner-friendly as possible. (: So, not leaving out any info that might be helpful for people not (so) familiar with certain tools, or the lingo that comes with them. I'd really love to see more programming beginners use Homebrew & pyenv (or chruby etc.) from the beginning as I believe it's generally a good idea not to mess with one's Mac system too much. But, for beginners, info on additional tools and how to use them can be quite overwhelming (and missing 'helper' messages can make navigation/usage of tools more difficult). So if I'm struggling with any of this, it must be n times harder for total beginners! And I'm afraid they're then more likely to just not go through all the trouble of trying to figure out how to do things (better). Anyway, cool, I'll change that one bit I was looking to change soon, and submit a PR! |
I didn't say I won't remove it. It's just keep for now for compatibility between previous release. |
Oh, so are you planning to remove it altogether? That would be a pity. ): It's a really, really useful feature to have. Btw. I thought about the issue some more, trying to figure out why I found the current instructions so confusing. I think it's because the variable says 'disable' for a function which will be disabled by default anyway! People will have to 'disable' something that's already disabled, when really, they want to turn on something that's turned off by default. I.e. wouldn't it make more sense to name it |
I guess the Anyways, I also had a little trouble understanding the message (which is why I googled it). I wasn't aware that pyenv-virtualenv sets PS1 since I'm setting PS1 myself in my It's probably a good idea to either include information in the README on how users can set up their prompt themselves, or link to a guide somewhere else. In my setup, I'm using the function updatePrompt {
# Styles
GREEN='\[\e[0;32m\]'
BLUE='\[\e[0;34m\]'
RESET='\[\e[0m\]'
# Base prompt: \W = working dir
PROMPT="\W"
# Current Git repo
if type "__git_ps1" > /dev/null 2>&1; then
PROMPT="$PROMPT$(__git_ps1 "${GREEN}(%s)${RESET}")"
fi
# Current virtualenv
if [[ $VIRTUAL_ENV != "" ]]; then
# Strip out the path and just leave the env name
PROMPT="$PROMPT${BLUE}{${VIRTUAL_ENV##*/}}${RESET}"
fi
PS1="$PROMPT\$ "
}
export -f updatePrompt
# Bash shell executes this function just before displaying the PS1 variable
export PROMPT_COMMAND='updatePrompt' |
@danmichaelo I agree (a link to) instructions should be included as it cannot be assumed that everyone who'd like to use pyenv-virtualenv knows how to write shell functions. As said before, for beginners it's tricky enough to work out how to get tools like pyenv(-virtualenv) running in the first place; if we want more folks to use cool tools (which I hope we all do!) we need to make sure they are accessible. I'll see if I can find time to try out your function, thanks for posting the code! |
@danmichaelo @kerstin newbie here, how can I use that shell function to have the prompt like virtualenv's? Thanks :D |
@GandaG Copy and paste the code into a file named |
@danmichaelo thanks! The prompt appeared after restarting so I guess I better not change anything (I have this bookmarked though) |
@GandaG, you won't need that piece of code just yet, only once the prompt message is removed (in future versions). Though it might not actually be applicable anymore then. (; We'll see. (I'll definitely want to keep the prompt change, so we might have to create our own workarounds in the future.) |
- pyenv/pyenv-virtualenv#135 (comment) - stopped matching searches in vim as they are typed
@yyuu @kerstin @danmichaelo I'm sorry I came to this thread really late but, do you guys mean that |
@athrunsun only virtualenv like prompt changing feature has been deprecated. I don't have any plan to deprecate |
@yyuu Thanks. It looks I can change to a specific virtualenv by |
@yyuu Can you clarify your last message? What's the difference between the "virtualenv like prompt changing feature" and |
I found some typo in my last comment. At least I don't have any plan to deprecate activate/deactivate |
I think the confusion is around what is meant by "prompt changing". To clarify, what is going to be removed is the bit where the PS1 is modified, correct? ie: I believe the message has been taken to mean "you will not be able to activate or deactivate virtualenvs from the terminal in the future". Am I correct in my understanding of what folks are possibly (mis)understanding? |
@mmatlock-shr Yeah, my assumption was that the visual indicator that one was in a directory with a virtualenv was going to disappear, i.e. that the |
Why not just keep it in, make it configurable but off by default? |
Having a prompt showing immediately that you're in a virtualenv is absolutely necessary and invaluable feature. I don't know how many times I've accidentally installed some stuff globally by using pip because I didn't pay enough attention to the prompt showing me that I hadn't activated virtualenv yet. |
Any news on this ? Why not exporting a environment variable, like |
I was looking for an answer. I tried to play a little bit with this, isn't that enough for you? (That's fine with me) export PS1='\n$(pyenv version-name)\n'$PS1 |
Thanks for the tip! I just prefer use it as prefix, but I liked your version too |
A slight change to @cglacet 's version makes the prompt look just like the default virtualenv behavior: export PS1='($(pyenv version-name)) '$PS1 yields something like:
I like his idea; it is simple, non-hacky, and easy to undo. |
Now its 2020 and the warning message is still there. I am glad to see that the functions
My suggestion would be
Thanks |
In the mean time I added a simple function to .bashrc function workon() {
pyenv activate "$@" 2> >(grep -v PYENV_VIRTUALENV_DISABLE_PROMPT)
} Usage: Shout-out to virtualenvwrapper! |
idk. if this is handy, but none of the other bash solutions quite replicate the default pyenv prompt behaviour in some way or another. I have put them together to do this which seems to work well. it hides the prompt if not in a virtualenv and revaluates with each new prompt - so it will change to be correct as you
adding this or similar to the README could be a reasonable substitute for removing/disabling the behaviour. although I'm not sure if this would work in shells other than bash? |
@LukeAI Thank you for providing the solution!
|
In cases where you have multiple version specified in eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"
# turn off deprecated pyenv prompt
export PYENV_VIRTUALENV_DISABLE_PROMPT=1
export BASE_PROMPT=$PS1
function updatePrompt {
if [[ "$(pyenv version-name)" != "system" ]]; then
PYENV_VER=$(pyenv version-name) # capture version name in variable
export PS1="(${PYENV_VER%%:*}) "$BASE_PROMPT # grab text prior to first ':' character
else
export PS1=$BASE_PROMPT
fi
}
export PROMPT_COMMAND='updatePrompt' |
So after of all, I don't need to concern that warning, right? |
I have slightly modified @rmorshea 's script, for people who change the global environment from export PYENV_VIRTUALENV_DISABLE_PROMPT=1
export BASE_PROMPT=$PS1
function updatePrompt {
PYENV_VER=$(pyenv version-name) # capture version name in variable
if [[ "${PYENV_VER}" != "$(pyenv global | paste -sd ':' -)" ]]; then # MODIFIED: "system" -> "$(pyenv global | paste -sd ':' -)"
export PS1="(${PYENV_VER%%:*}) "$BASE_PROMPT # grab text prior to first ':' character
else
export PS1=$BASE_PROMPT
fi
}
export PROMPT_COMMAND='updatePrompt'
|
Solution that leaves the pyenv-virtualenv behavior untouched, but just sends the warning message to
|
For those who use pyenv + poetry # turn off deprecated pyenv prompt
export PYENV_VIRTUALENV_DISABLE_PROMPT=1
export BASE_PROMPT=$PS1
function updatePrompt {
if [[ ! -z $VIRTUAL_ENV ]]; then
export PS1="($(basename $VIRTUAL_ENV)) "$BASE_PROMPT
elif [[ "$(pyenv version-name)" != "system" ]]; then
PYENV_VER=$(pyenv version-name) # capture version name in variable
export PS1="(${PYENV_VER%%:*}) "$BASE_PROMPT # grab text prior to first ':' character
else
export PS1=$BASE_PROMPT
fi
}
export PROMPT_COMMAND="updatePrompt;$PROMPT_COMMAND" |
I've done this one based on @LukeAI's answer, where it will only print the active env name by finding it in the list that export PYENV_VIRTUALENV_DISABLE_PROMPT=1
export BASE_PROMPT=$PS1
function updatePrompt {
if [[ "$(pyenv virtualenvs)" == *"* $(pyenv version-name) "* ]]; then
export PS1='($(pyenv version-name)) '$BASE_PROMPT
else
export PS1=$BASE_PROMPT
fi
}
export PROMPT_COMMAND='updatePrompt' I hope it helps! |
The only thing need todo is to rm the warning msg. |
So... is this "future release" still coming, or has this message annoyed thousands of people over the course of seven years for no reason? |
@yyuu , I believe you're in the best position to answer this 🙂 |
Would it be acceptable to keep the current behaviour but disable the warning, at least until the release happens, by setting |
These solutions kinda slowed down my shell on every command press so I had to revert. When I realized this originated in 2015 I was delighted in a way b/c it doesn't look like this default functionality will be removed since it hasn't been changed thus far. |
Kudos to @native-api 🥹 Hoping it will make it to homebrew as well 🤞 |
Hi, I updated my Homebrew install and I'm now getting an info message displayed whenever I'm changing into directories that have a
.python-version
file in them (I'm guessing? I'm not entirely sure on what triggers the behaviour).It says:
pyenv-virtualenv: prompt changing will be removed from future release. configure
export PYENV_VIRTUALENV_DISABLE_PROMPT=1' to simulate the behavior.`but it's not really clear to me from that message how the prompt will change in the future and how that variable is supposed to work, i.e. what its expected behaviour is.
I added the var to my shell file just to try it out, and the resulting prompt is definitely not what I want, as it seems to get stuck in a mode where it always displays the currently activated virtualenv, regardless of where I am in my file system.
Re: what's going to change:
Will only the active/deactive messages disappear? Or both that and the prompt prefix that displays the virtualenv's name, like so
(myvirtualenv) mymachine:~$
?And a general question, not directly related to this issue: are you accepting PRs for improving documentation? Because I'd really like to add a bit of info to this repo's README that would've saved me lots of time trying to figure out a particular problem I had.
The text was updated successfully, but these errors were encountered: