ohmyzsh: pyenv plugin creates output that powerlevel10k does not like
Describe the bug As of a recent update (not sure exactly in which version change), I started to receive the following output upon opening a new terminal window:
[WARNING]: Console output during zsh initialization detected.
When using Powerlevel10k with instant prompt, console output during zsh initialization may indicate issues.
You can:
-
Recommended: Change ~/.zshrc so that it does not perform console I/O after the instant prompt preamble. See the link below for details.
- You will not see this error message again.
- Zsh will start quickly and prompt will update smoothly.
-
Suppress this warning either by running p10k configure or by manually defining the following parameter:
typeset -g POWERLEVEL9K_INSTANT_PROMPT=quiet
- You will not see this error message again.
- Zsh will start quickly but prompt will jump down after initialization.
-
Disable instant prompt either by running p10k configure or by manually defining the following parameter:
typeset -g POWERLEVEL9K_INSTANT_PROMPT=off
- You will not see this error message again.
- Zsh will start slowly.
-
Do nothing.
- You will see this error message every time you start zsh.
- Zsh will start quickly but prompt will jump down after initialization.
For details, see: https://github.com/romkatv/powerlevel10k/blob/master/README.md#instant-prompt
– console output produced during zsh initialization follows –
WARNING: pyenv init - no longer sets PATH.
Run pyenv init to see the necessary changes to make to your configuration.
To Reproduce Steps to reproduce the behavior, for example:
- Enable this plugin: pyenv
- Be a powerlevel10k user
- Open a new terminal, which initializes zsh
- See error
Expected behavior The pyenv plugin should not produce any output
Screenshots and/or Recordings See text copy/pasted above
Desktop (please complete the following information):
- OS / Distro: Pop OS 20.04
- Latest ohmyzsh update?: yes
- ZSH Version: 5.8
- Terminal emulator: Gnome Terminal
Possible fix
On the line before https://github.com/ohmyzsh/ohmyzsh/blob/d646884add277d134235a9b18ab755388d6e0d8d/plugins/pyenv/pyenv.plugin.zsh#L32, add eval "$(pyenv init --path)"
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 10
- Comments: 18 (9 by maintainers)
The
pyenvplugin takes take ofpyenv init -andpyenv virtualenv -, yes 😃Just in case anyone is clueless about the difference between
.zshrcand.zprofile(like I was until a minute ago)….zshrc: Stays the same (at least, it did for me).zprofileI had to add the new stuff that includeseval "$(pyenv init --path)"… which leads me to wonder if maybe I don’t need
eval "$(pyenv init -)"in my.zshrc… like maybe thepyenvOMZ plugin is doing that for me?As was documented in the pyenv plugin, you need to add these lines to
.profileand.zprofile:and restart the user session (log out and log back in).
sometimes evaluating with
. "$(pyenv init --path)"doesn’t work, what only worked for me is adding the evaluated outputexport PATH="/Users/aali/.pyenv/shims:${PATH}"to my ~/.zprofile.zshenvis sourced for all invocations of the shell, and not until zsh is launched, so it’s not the best solution here. On Ubuntu, GDM usesshas the login shell, so.zprofileis never sourced 🥴 my solution, to make the PATH available to the system, is to put the exports in.profile, and have.zprofilesource that file. Then, when you SSH into the computer, the.profileis still sourced.@NeilGirdhar not sure who should make the call about closing it, but unless there’s anything that can be done in the
pyenvplug-in to improve the situation, closing it seems reasonable.This is because
pyenvhas updated to be more explicit about PATH handling. Now, the.profilefile should setand the
.bashrcequivalent should set