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

Feature: force ruby version for specific commands #276

Closed
sheerun opened this Issue Nov 15, 2012 · 14 comments

Comments

Projects
None yet
4 participants
@sheerun

sheerun commented Nov 15, 2012

I'd like to run tmuxinator and other similar gem-based tools using same ruby version and don't care in what directory I'm in. I'd really like to see command like:

rbenv freeze tmuxinator

That ensures tmuxinator is always run using currently selected ruby version.

What do you think?

@radar

This comment has been minimized.

Show comment
Hide comment
@radar

radar Dec 12, 2012

Contributor

While this is something that would be nice for you, there have been no other feature requests like this as far as I can tell.

Why wouldn't you just ensure that the ruby version is correct before running this gem's bin file? You could even make an alias to do that:

alias alias_name_goes_here='rbenv local && tmuxinator'

Contributor

radar commented Dec 12, 2012

While this is something that would be nice for you, there have been no other feature requests like this as far as I can tell.

Why wouldn't you just ensure that the ruby version is correct before running this gem's bin file? You could even make an alias to do that:

alias alias_name_goes_here='rbenv local && tmuxinator'

@radar radar closed this Dec 12, 2012

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Dec 12, 2012

It's because I develop projects that use 1.8.7, but some tools I use (unrelated to project) work only onder 1.9.2+. I understand I can simulate it by aliasing RBENV_VERSION=1.9.2... tmuxinator, but it seems cumbersome.

I think it could be helpful for other people because there are more and more ruby commandline tools, and they can require specific ruby version. #!/usr/bin/env ruby is just not reliable enough by itself.

Anyway, I hope someone'll upvote that issue in the future.

sheerun commented Dec 12, 2012

It's because I develop projects that use 1.8.7, but some tools I use (unrelated to project) work only onder 1.9.2+. I understand I can simulate it by aliasing RBENV_VERSION=1.9.2... tmuxinator, but it seems cumbersome.

I think it could be helpful for other people because there are more and more ruby commandline tools, and they can require specific ruby version. #!/usr/bin/env ruby is just not reliable enough by itself.

Anyway, I hope someone'll upvote that issue in the future.

@mislav

This comment has been minimized.

Show comment
Hide comment
@mislav

mislav Dec 12, 2012

Member

@sheerun: I totally understand you. I have the same setup, where some Ruby tools are use are unrelated to the runtime of the current project and don't have to be in its local version of Ruby. Actually, they usually only work on one ruby (my main install).

However, we don't have a clear vision how to handle this in rbenv yet. If you write an extra command for rbenv and use it with some success, you could suggest it here and we can have a look.

Member

mislav commented Dec 12, 2012

@sheerun: I totally understand you. I have the same setup, where some Ruby tools are use are unrelated to the runtime of the current project and don't have to be in its local version of Ruby. Actually, they usually only work on one ruby (my main install).

However, we don't have a clear vision how to handle this in rbenv yet. If you write an extra command for rbenv and use it with some success, you could suggest it here and we can have a look.

@sstephenson

This comment has been minimized.

Show comment
Hide comment
@sstephenson

sstephenson Dec 12, 2012

Contributor

I love the idea of rbenv freeze. I think it ought to be possible to implement it as a plugin. If not, let's look into adding the hooks necessary to make it possible.

Contributor

sstephenson commented Dec 12, 2012

I love the idea of rbenv freeze. I think it ought to be possible to implement it as a plugin. If not, let's look into adding the hooks necessary to make it possible.

@mislav

This comment has been minimized.

Show comment
Hide comment
@mislav

mislav Dec 12, 2012

Member

OK, reopened this to stay as a TODO item! @sheerun, we welcome suggestions/code.

Member

mislav commented Dec 12, 2012

OK, reopened this to stay as a TODO item! @sheerun, we welcome suggestions/code.

@mislav mislav reopened this Dec 12, 2012

@sstephenson

This comment has been minimized.

Show comment
Hide comment
@sstephenson

sstephenson Dec 12, 2012

Contributor

By the way, @josh's brew-gem solves this problem (in a different way) if you are on a Mac.

Contributor

sstephenson commented Dec 12, 2012

By the way, @josh's brew-gem solves this problem (in a different way) if you are on a Mac.

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Dec 12, 2012

I'm working on rbenv lock command right now.

sheerun commented Dec 12, 2012

I'm working on rbenv lock command right now.

@mislav

This comment has been minimized.

Show comment
Hide comment
@mislav

mislav Dec 12, 2012

Member

FWIW, I have my own rbenv lock but it's not related to this. It's about "locking" the version of ruby in the current project by having .rbenv-version written out if it doesn't exist yet.

$ cat `which rbenv-lock`                                                                                                                                        [master] 
#!/bin/sh
rbenv local "$(rbenv version-name)"
Member

mislav commented Dec 12, 2012

FWIW, I have my own rbenv lock but it's not related to this. It's about "locking" the version of ruby in the current project by having .rbenv-version written out if it doesn't exist yet.

$ cat `which rbenv-lock`                                                                                                                                        [master] 
#!/bin/sh
rbenv local "$(rbenv version-name)"
@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Dec 13, 2012

Maybe generalize this in similar way the ~/.rbenv/global and .rbenv-version work. I'm thinking about ~/.rbenv/locks and .rbenv-locks files listing commands along ruby versions they should be executed with:

tmuxinator: 1.9.3-p194-perf
awesomize: ree-1.8.7-2012.02

The command's Ruby version listed in .rbenv-locks have precedence over version listed in ~/.rbenv/locks.

The command changed would be rbenv-version-name. It would search for Ruby version for given comand in:

  1. RBENV_VERSION
  2. .rbenv-locks
  3. ~/.rbenv/locks
  4. .rbenv-version
  5. ~/.rbenv/global
  6. PATH

Additionally there would exist rbenv lock and rbenv unlock commands for editing lock files:

rbenv lock --list                # prints concatenated locks list
rbenv lock tmuxinator            # writes to `.rbenv-locks`
rbenv lock --global tmuxinator   # writes to `~/.rbenv/locks`
rbenv unlock tmuxinator          # removes command from `.rbenv-locks`
rbenv unlock --global tmuxinator # removes command from`~/.rbenv/locks`

I don't know how you, but I see nice symmetry this command introduces. We could as easily set ruby version for whole directories as single commands within those directories (or system user).

sheerun commented Dec 13, 2012

Maybe generalize this in similar way the ~/.rbenv/global and .rbenv-version work. I'm thinking about ~/.rbenv/locks and .rbenv-locks files listing commands along ruby versions they should be executed with:

tmuxinator: 1.9.3-p194-perf
awesomize: ree-1.8.7-2012.02

The command's Ruby version listed in .rbenv-locks have precedence over version listed in ~/.rbenv/locks.

The command changed would be rbenv-version-name. It would search for Ruby version for given comand in:

  1. RBENV_VERSION
  2. .rbenv-locks
  3. ~/.rbenv/locks
  4. .rbenv-version
  5. ~/.rbenv/global
  6. PATH

Additionally there would exist rbenv lock and rbenv unlock commands for editing lock files:

rbenv lock --list                # prints concatenated locks list
rbenv lock tmuxinator            # writes to `.rbenv-locks`
rbenv lock --global tmuxinator   # writes to `~/.rbenv/locks`
rbenv unlock tmuxinator          # removes command from `.rbenv-locks`
rbenv unlock --global tmuxinator # removes command from`~/.rbenv/locks`

I don't know how you, but I see nice symmetry this command introduces. We could as easily set ruby version for whole directories as single commands within those directories (or system user).

@mislav

This comment has been minimized.

Show comment
Hide comment
@mislav

mislav Dec 13, 2012

Member

How about this new lock command simply edits an existing shim for a certain executable?

$ rbenv lock tmuxinator 1.9.3-p194-perf

# hardcodes into ~/.rbenv/shims/tmuxinator:
export RBENV_VERSION=1.9.3-p194-perf
Member

mislav commented Dec 13, 2012

How about this new lock command simply edits an existing shim for a certain executable?

$ rbenv lock tmuxinator 1.9.3-p194-perf

# hardcodes into ~/.rbenv/shims/tmuxinator:
export RBENV_VERSION=1.9.3-p194-perf
@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Dec 13, 2012

That was my initial idea (actually I've implemented it by now), but then I though the solution based on files is more powerful and clean at the same time. The question is if there is any real advantage of .rbenv-locks files (i.e. setting ruby version for commands within one project, not within user account).

sheerun commented Dec 13, 2012

That was my initial idea (actually I've implemented it by now), but then I though the solution based on files is more powerful and clean at the same time. The question is if there is any real advantage of .rbenv-locks files (i.e. setting ruby version for commands within one project, not within user account).

@sstephenson

This comment has been minimized.

Show comment
Hide comment
@sstephenson

sstephenson Dec 13, 2012

Contributor

I'm struggling to think of a case where I'd want to lock a command to a particular version in a specific directory.

The use case for me would be to avoid having to specify the version when I run a command like bcat that's installed as a gem in a particular version.

Thinking more, I wonder if this feature could be less like "lock" or "freeze" and more like "default." I.e., don't force the specified Ruby version, but fall back to it if the command isn't present in the current (local, shell, or global) version.

Contributor

sstephenson commented Dec 13, 2012

I'm struggling to think of a case where I'd want to lock a command to a particular version in a specific directory.

The use case for me would be to avoid having to specify the version when I run a command like bcat that's installed as a gem in a particular version.

Thinking more, I wonder if this feature could be less like "lock" or "freeze" and more like "default." I.e., don't force the specified Ruby version, but fall back to it if the command isn't present in the current (local, shell, or global) version.

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Dec 13, 2012

I like the fallback idea.

sheerun commented Dec 13, 2012

I like the fallback idea.

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Jan 25, 2013

I think we can close this issue because of #187

sheerun commented Jan 25, 2013

I think we can close this issue because of #187

@sheerun sheerun closed this Jan 25, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment