Question regarding prompt changing

[keikoro]

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.

[yyuu]

In pyenv-virtualenv prior to v20151222, there were some known issues related to management of $PATH and shell's prompt (#51, #69, #80).

To solve all those issues intrinsically, pyenv-virtualenv stopped using activate script generated by virtualenv, venv and conda env (#104). The virtual environments will be pick up via shims just like other ordinary versions in pyenv (e.g. 2.7.11, 3.5.1, etc.). Because these virtual environments are just a pyenv version now, I don't like to do something special for them as much as possible. I added that deprecation warning and I will remove the prompt changing feature in future releases (actually, the feature has already been removed for fish shell since it had known problem).

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 pyenv versions, like other non-virtual versions in pyenv. Any users can configure their shell to show the name of activated virtualenv in their prompt like before, but pyenv-virtualenv will stop doing it by default in future release.

Any contributions are always welcomed. We need more hands and eyes to improve things, especially for documentation since I am pretty bad at documentation 😛

[keikoro]

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 PYENV_VIRTUALENV_DISABLE_PROMPTvariable)?

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!

[yyuu]

I didn't say I won't remove it. It's just keep for now for compatibility between previous release.

[keikoro]

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 PYENV_VIRTUALENV_ENABLE_PROMPT and have people set it to 0 in their shell config if they want to (re)enable the prompt?

[danmichaelo]

I guess the PYENV_VIRTUALENV_DISABLE_PROMPT variable is just a temporary solution to let you test how it will be once the feature is removed. It will probably go away together with the feature.

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 ~/.bashrc, and therefore export PYENV_VIRTUALENV_DISABLE_PROMPT=1 did nothing.

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 $VIRTUAL_ENV variable, which I expect still will be available:

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'

[keikoro]

@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!

[dh-nunes]

@danmichaelo @kerstin newbie here, how can I use that shell function to have the prompt like virtualenv's? Thanks :D

[danmichaelo]

@GandaG Copy and paste the code into a file named .bashrc (or .bash_profile) in your home folder should work. If you're not accustomed to these files, just google them.

[dh-nunes]

@danmichaelo thanks! The prompt appeared after restarting so I guess I better not change anything (I have this bookmarked though)

[keikoro]

@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.)

[athrunsun]

@yyuu @kerstin @danmichaelo I'm sorry I came to this thread really late but, do you guys mean that pyenv activate/deactivate is no longer recommended and users should create .python-version and let pyenv handle virtualenv auto switching instead?

[yyuu]

@athrunsun only virtualenv like prompt changing feature has been deprecated.

I don't have any plan to deprecate pyenv activate and pyenv deactivate. They should work as long as pyenv's PYENV_VERSION environment variable works.

[athrunsun]

@yyuu Thanks. It looks I can change to a specific virtualenv by pyenv shell as well, which is more convenient.

[kmantel]

@yyuu Can you clarify your last message? What's the difference between the "virtualenv like prompt changing feature" and pyenv activate/deactivate? If the latter is being removed in a future version will there be any way to run different venvs within a single directory, say from a script? From what I understand using the .python-version auto switches using only one environment per directory

[yyuu]

I found some typo in my last comment. At least I don't have any plan to deprecate activate/deactivate

[mmatlock-shr]

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:
(my-cool-env) ~/Documents/projects/my-cool-proj $
That () bit at the beginning changing upon activating or deactivating a certain virtualenv. That will no longer happen in the future?

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?

[keikoro]

@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 (my-cool-env) bit in front of ~/Documents/projects/my-cool-proj $ would get removed.

[geoidesic]

Why not just keep it in, make it configurable but off by default?
Best of both worlds.

[svenvarkel]

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.

[brunetton]

Any news on this ?
As @svenvarkel mentionned, it's absolutely necessary to have a way to know whether a virtual env is activated or not.
I'm very surprised that any env var is set by pyenv to indicate that a virtual env is being used in this shell.

Why not exporting a environment variable, like $VIRTUAL_ENV set by venv or virtualenv ?

[cglacet]

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

[arcanosam]

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

[jonathanmcmahon]

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:

(myvenv) $

I like his idea; it is simple, non-hacky, and easy to undo.

[CBtiger]

Now its 2020 and the warning message is still there. I am glad to see that the functions

• pyenv activate
• pyenv deactivate
• the prompt showing any non-system virtualenv
  are still in. I also agree to the others that those functions are essential. They were the whole point for me to install pyenv on my linux system in the first place: transparent and easy handling for python out of the box.

My suggestion would be

• remove the warning, because its annoying.
• If, in the future, anything gets removed or disabled by default. THEN (and only then) please add a section in the README.MD on how to get the function back. When I download an update without checking the github page (e.g. by script) and the prompt is suddenly gone I am going to check the github page anyway. If I would see is a "Changed behavior" section at the top I am sure going to read it, won't i?

Thanks

[millerdev]

In the mean time I added a simple function to .bashrc

function workon() {
    pyenv activate "$@" 2> >(grep -v PYENV_VIRTUALENV_DISABLE_PROMPT)
}

Usage: workon VENV_NAME

Shout-out to virtualenvwrapper!

[LukeAI]

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 cd in and out of different envs and the system

  export PYENV_VIRTUALENV_DISABLE_PROMPT=1                                                                                                                                                                         
  export BASE_PROMPT=$PS1                                                                                                                                                                                           
  function updatePrompt {                                                                                                                                                                                           
      if [[ "$(pyenv version-name)" != "system" ]]; then                                                                                                                               
          export PS1='($(pyenv version-name)) '$BASE_PROMPT                                                                                                                                                         
      else                                                                                                                                                                                                          
          export PS1=$BASE_PROMPT                                                                                                                                                                                   
      fi                                                                                                                                                                                                            
  }                                                                                                                                                                                                                 
  export PROMPT_COMMAND='updatePrompt' 

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?

[chunyunma]

@LukeAI Thank you for providing the solution!
I had to make a few changes to make it work (I am using zsh).

export PYENV_VIRTUALENV_DISABLE_PROMPT=1
export BASE_PROMPT=$PS1
function updatePrompt {
    if [[ "$(pyenv version-name)" != "system" ]]; then
        # the next line should be double quote; single quote would not work for me
        export PS1="($(pyenv version-name)) "$BASE_PROMPT 
    else
        export PS1=$BASE_PROMPT
    fi
}
export PROMPT_COMMAND='updatePrompt'
precmd() { eval '$PROMPT_COMMAND' } # this line is necessary for zsh

[rmorshea]

In cases where you have multiple version specified in .python-version the prompt gets really long. Amending the commented lines below allowed me to just show the first version listed in the file:

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'

[JinYeJin]

So after of all, I don't need to concern that warning, right?

[keisuke-nakata]

I have slightly modified @rmorshea 's script, for people who change the global environment from system:

  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'

| paste -sd ':' - is needed because pyenv global prints line-break separated virtualenv names.

[ollie-bell]

Solution that leaves the pyenv-virtualenv behavior untouched, but just sends the warning message to /dev/null

sed -i '/prompt changing will be removed from future release/s/1>&2/> \/dev\/null/' ~/.pyenv/plugins/pyenv-virtualenv/bin/pyenv-sh-activate

[roytseng-tw]

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"

[saya-rbt]

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 pyenv virtualenvs returns. Therefore, system won't be printed, and neither will the pyenv project version.

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!

[current-liu]

The only thing need todo is to rm the warning msg.

[garlic-os]

So... is this "future release" still coming, or has this message annoyed thousands of people over the course of seven years for no reason?

[native-api]

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 🙂

[m-legrand]

Would it be acceptable to keep the current behaviour but disable the warning, at least until the release happens, by setting export PYENV_VIRTUALENV_DISABLE_PROMPT=0? It could raise an error after the release is done if this behaviour is no longer supported.

[jeff-zone]

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.

[sun-mir]

Kudos to @native-api

🥹
#447

Hoping it will make it to homebrew as well 🤞
Homebrew/homebrew-core#165989