Latest pyenv versions require different initialisation

[SwampFalc]

The latest versions of pyenv no longer support the initialisation commands that are currently used in the plugin.

Error message upon starting a new terminal:

WARNING: `pyenv init -` no longer sets PATH.
Run `pyenv init` to see the necessary changes to make to your configuration.

Expected Behavior

• Using the pyenv plugin should work without error message.
• The shims folder is no longer in PATH.

Current Behavior

Error message. No shims in PATH.

Possible Solution

Hard to say... The fix in and of itself is simple, but I do not expect it to be backwards compatible. So anyone that updates bashit but not their pyenv would end up with the inverse problem.

Fix: use pyenv init --path instead of pyenv init -

Steps to Reproduce

1. Update pyenv following https://github.com/pyenv/pyenv#upgrading
2. Open a new terminal

Your Environment

• Bash-it version used: latest
• pyenv version used: also latest (1.2.27-41-gddf952ab)

[cornfeedhobo]

Well that's a bummer. I'll try to take a look this weekend.

[SwampFalc]

Looking at it, I think pyenv/pyenv#1920 is probably the place with the most explanations about what's happening, why and what their plans for the future are.

[davidpfarrell]

Thanks for reporting this !

So changes like this one have been a long-time-coming since you're not really supposed to modify the $PATH variable within .bashrc, which is where these types of evals usually live.

I have an idea for dealing with this particular instance:

The devs have made the pyenv init --path effects transparent here:

• https://github.com/pyenv/pyenv#advanced-configuration

Sets up your shims path. This is the only requirement for pyenv to function properly. You can do this by hand by prepending $(pyenv root)/shims to your $PATH.

With this transparency, we have permission to manually add the shims folder to our path, ie something like:

eval "$(pyenv init -)"
# In case we're using a new pyenv, manually add the shims to the path 
# pathmunge will safely abort if the path entry is already present
pathmunge "$(pyenv root)/shims" before

This could be a one-line fix that gets us past the issue for now ...

[SwampFalc]

That approach sounds more backwards compatible.
However, I do believe the order should be reversed. Since pyenv init - rehashes the shims, I suspect it might need the shims folder in the path already.

[davidpfarrell]

Since pyenv init - rehashes the shims, I suspect it might need the shims folder in the path already.

Doh!, yes that is correct.

An issue with setting the path first is that pyenv doesn't check the path before generating the new path statement (verified locally), so if the shims folder is already on the path, will be added to the path again ... perhaps not a terrible issue but less than ideal.

So, reversing the order could be a quick-fix while we work on a better one.

I suspect we'll need multiple plugins with some kind of tag in the name to distinguish them ...

[cornfeedhobo]

I've deleted my last comment because it was too long and not accurate. Instead, I've opened a PR that solves the problem, and will follow up with any discussion there. Thanks @SwampFalc & @davidpfarrell !