rbenv update

[mislav]

Should we have an rbenv update command? /cc @rkh

It would work only if RBENV_ROOT is where rbenv is installed, and if it's a git repo.

I think it might be useful, considering the slow release cycle, and especially now that we have rbenv --version capable of displaying edge versions from git.

[sstephenson]

Already working on it, but want to get 0.4.0 out the door first.

[rkh]

+1, though it would only be really useful if it also updates plugins (like my update plugin does) or at least ruby-build.

[taqtiqa-mark]

@rkh, @sstephenson

@justinclift and I have been working on rbenv plugin <...> for rbenv-installer. We've hit a wrinkle which I'd appreciate any hints or tips on.
Once it works in that context I'll extract it to as separate plugin.
Maybe after it has been used in anger it could be merged into rbenv?

[mislav]

A command to manage plugins would be interesting but not sure if we would have it in core. I'm not completely sold yet, but others might be. However since this issue is about an update command that will primarily update rbenv and plugins second, it's best that you open a separate issue/pull request for a plugin command proposal.

[taqtiqa-mark]

I'm happy with a plugin plugin.

[kevinSuttle]

Sort of like vim-pathogen for Rbenv? I like it.

[mislav]

@sstephenson: How about an rbenv-update command which updates rbenv itself from git and executes update hooks from plugins? That way ruby-build could publish a hook that updates itself from git as well.

[wadkar]

@mislav , if it's okay - I recommend that we "get inspired" from pyenv's update plugin. Pyenv folks are nice and they consider rbenv{,-build} as upstream. So it will be a nice fit.

I have also read through the pyenv-update bash script and I think it's pretty solid in terms of quoting things, and making sure things don't blow up. We just need to change few variables from PYENV_ROOT to RBENV_ROOT.

Do you want it to be part of rbenv core or as a separate plugin? In either case, I will be happy to submit a PR/repo.

[cornfeedhobo]

I've started to use basher to manage these tools.

Otherwise, my +1 is for what @wadkar said; a rbenv-update plugin.

[olivierlacan]

Every time I run rbenv instlal <new_version> and I get this message I think:

We're so, so close to a nice experience for Ruby upgrades, it's really a shame rbenv doesn't just run this update in the background

ruby-build: definition not found: 3.0.1

See all available versions with `rbenv install --list'.

If the version you need is missing, try upgrading ruby-build:

  git -C /Users/olivierlacan/.rbenv/plugins/ruby-build pull

Having to run git pull is not the end of the world, but considering a tool like Homebrew routinely does it behind its own commands, it would really make a ton of sense to just run it (and be clear that rbenv is running a git pull).

PS: I would love to contribute to help this become a reality, but in the immediate future I sadly don't have the time. I wonder if anyone involved with this thread does?

[mislav]

@olivierlacan I do believe that this should be easier for the user, and what you're suggesting sounds completely reasonable.

However, there's something that feels slightly risky about software that updates itself by itself without any intervention from the user—especially when the software has never done so before. I'm not sure if we should alienate our users' trust by starting to automatically update ruby-build on every rbenv install.

I like the approach of ruby-install (an alternative to ruby-build): they are able to install new Ruby versions as they come out without having to upgrade ruby-install itself: https://github.com/postmodern/ruby-install#anti-features

[jasonkarns]

re: auto-updating

I really like this idea. Given that the rbenv-update plugin exists, but there hasn't been any movement to pull it into core, this feels like the perfect feature to add to the plugin itself.

ruby-build's rbenv-install subcommand executes before and after install hooks. It seems feasible that the rbenv-update plugin could add an install hook to run itself. (Perhaps even guarded by an opt-in environment variable to avoid being a breaking change?)

[rkh]

FWIW while I still use rbenv, I semi-automatically update it and ruby-build via homebrew now, and thus don't actually use rbenv-update myself anymore. I am happy to offer maintenance/commit rights if someone wants to (ideally someone using it) or have it output some message if it is no longer useful.

[jasonkarns]

@rkh I believe I still have commit rights on that repo so if someone tackles a PR, I could handle reviewing and releasing.

[olivierlacan]

I think the concern about self-updating can be handled by a prompt.

3.0.1 is available but rbenv needs to update itself in order to install it, is that ok? Yes/No

@jasonkarns I’m down !

[olivierlacan]

@jasonkarns So, should we use ruby-build hooks when an attempt to rbenv install 4.0.0 is made to check for an available 4.0.0 definition and if there is even a partial match that isn't currently available in rbenv install -l, offer to run rbenv-update (with a prompt) before replaying the original rbenv install 4.0.0 against the now-up-to-date rbenv/ruby-build pair?

I realize saying this out loud how much is involved for this to happen. And I'm a bit exhausted, but does that even still sound like something reasonable @mislav?

[mislav]

I realize saying this out loud how much is involved for this to happen. And I'm a bit exhausted, but does that even still sound like something reasonable @mislav?

Thanks for thinking long and hard about this. Yes, this does sounds like something that could improve the user experience when installing new versions. However, I would not couple this to rbenv-update, since rbenv-update updates rbenv and all its plugins, and we're only interested in updating ruby-build. So I would move this conversation to ruby-build, add an auto-updater there (we don't even need a hook; we could just bake it into rbenv-install). Of course, the whole thing would only work if ruby-build was installed via git.

I would also avoid a prompt, because prompts are annoying, so if someone checked out ruby-build via git, we can just assume that they don't mind if we fast-forward it to the latest version.