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

Question regarding prompt changing #135

Closed
keikoro opened this issue Dec 27, 2015 · 39 comments
Closed

Question regarding prompt changing #135

keikoro opened this issue Dec 27, 2015 · 39 comments

Comments

@keikoro
Copy link
Contributor

keikoro commented Dec 27, 2015

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
Copy link
Collaborator

yyuu commented Dec 28, 2015

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
Copy link
Contributor Author

keikoro commented Dec 28, 2015

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
Copy link
Collaborator

yyuu commented Dec 29, 2015

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

@yyuu yyuu closed this as completed Dec 29, 2015
@keikoro
Copy link
Contributor Author

keikoro commented Dec 31, 2015

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
Copy link

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
Copy link
Contributor Author

keikoro commented Jan 2, 2016

@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
Copy link

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

@danmichaelo
Copy link

@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
Copy link

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

@keikoro
Copy link
Contributor Author

keikoro commented Feb 21, 2016

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

jmeridth added a commit to jmeridth/dotfiles that referenced this issue Jun 24, 2016
- pyenv/pyenv-virtualenv#135 (comment)
- stopped matching searches in vim as they are typed
@athrunsun
Copy link

@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
Copy link
Collaborator

yyuu commented Dec 26, 2016

@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
Copy link

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

@kmantel
Copy link

kmantel commented Apr 16, 2018

@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
Copy link
Collaborator

yyuu commented Apr 16, 2018

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

@mmatlock-shr
Copy link

mmatlock-shr commented May 2, 2018

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
Copy link
Contributor Author

keikoro commented May 11, 2018

@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
Copy link

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

@svenvarkel
Copy link

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
Copy link

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
Copy link

cglacet commented Nov 30, 2019

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
Copy link

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
Copy link

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
Copy link

CBtiger commented May 5, 2020

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
Copy link

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
Copy link

LukeAI commented Sep 29, 2020

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
Copy link

@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
Copy link

rmorshea commented Oct 27, 2020

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
Copy link

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

@keisuke-nakata
Copy link

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
Copy link

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
Copy link

roytseng-tw commented Jun 13, 2021

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
Copy link

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
Copy link

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

@garlic-os
Copy link

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
Copy link
Member

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
Copy link

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
Copy link

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
Copy link

sun-mir commented Apr 5, 2024

Kudos to @native-api

🥹
#447

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests