is putting "eval "$(pyenv init -)"" in ~/.bash_profile really a good suggestion?

[AmaiKinono]

It's suggested in README.md to put eval "$(pyenv init -)" (and environment variables) in ~/.bash_profile, which may be not reasonable.

I am a (manjaro) Linux user. As far as I am concerned, ~/.bash_profile is not sourced when logging in under X (which means, under a graphical environment). Here's a little experiment:

• put export USING_TTY=1 in ~/.bash_profile, reboot the computer.
• open a terminal emulator, run $ echo $USING_TTY, nothing is printed.
• switch to a text tty, run $ echo $USING_TTY, "1" is printed.

Most desktop environments sources ~/.profile when logging in, so that should be the right place for Linux users to put environment variables and eval $(pyenv init -) in. When using text tty, only ~/.bash_profile is sourced, but it's a common practice to source ~/.profile and ~/.bashrc inside ~/.bash_profile, so this would make pyenv works both on desktop environment and text tty.

Please tell me if I am wrong.

Btw, here's a little problem. I myself put these in ~/.profile, and most of the functionalities work well under a desktop environment. $ which python gives me ~/.pyenv/shims/python, which should be a sign that I'm doing it right, but $ pyenv shell gives pyenv: shell integration not enabled. Run 'pyenv init' for instructions.. Does anybody know why this happens?

Update: I found I have to put export -f pyenv after eval "$(pyenv init -)" to export the function for sub-shells to use. This fixes the above problem.

[georgalis]

Good observation about all the different ways to bootstrap your environment! I've supported many shells (bash, bourne, zsh, ksh, ash, etc) on different OS (Linux, BSD, Darwin) at different sites. I've also created a tool set of command line functions and aliases. Getting your shell all setup with tuned and bug free preferences can take forever and a week and it's the last thing you want to fix when you've got other work to do. When users ask for help they generally don't want you refactoring their multiple shell conf files either.

Here's the standard I use when I'm setting up a system or my own accounts. All of my functions and aliases go into .profile (including all the stuff that has been added to user's bashrc, bash_profile, etc). In .profile, I use bourne compatible scripting to determine the OS, shell, and installed programs, with conditionals to set only appropriate environment, being careful to branch early for non interactive shells (so ssh works as expected)
/usr/bin/tty -s || return # the following for interactive sessions only

...os and shells specific aliases and functions...
...then, at the end of the file, I source $HOME/.profile.local if it exists, and report.

# if exists, source .profile.local
[ -e "$HOME/.profile.local" ] && . "$HOME/.profile.local" && echo "$HOME/.profile.local" || true
echo "$HOME/.profile"

This way I can keep a standard .profile that can be freely updated,
https://github.com/georgalis/pub/blob/master/skel/.profile
and host or user specific environment is always the same place, .profile.local

@AmaiKinono I don't think there is a good answer about where to set your environment to use pyenv, because it depends on the system and the user. Users have to maintain their environment and there are a lot of systems and standards to choose from. It might be better to just instruct users what to put in their environment, if you want to submit a patch for the docs, but I would close this issue in any event. :)

Thanks for the tip on exporting functions!

[AmaiKinono]

I have created a PR (#1359), please see if the changes are reasonable.