Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1065150 - do not install rubypick along with ruby
Summary: do not install rubypick along with ruby
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: ruby
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jeroen van Meeuwen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-14 03:21 UTC by postmodern
Modified: 2014-04-24 05:51 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-22 08:32:41 UTC


Attachments (Terms of Use)

Description postmodern 2014-02-14 03:21:02 UTC
Currently, the ruby package install a /usr/bin/ruby-mri executable and also requires /usr/bin/ruby, which the rubypick package provides. This causes the rubypick switcher script [1] to always be installed along with ruby. Instead, rubypick should be an optional dependency which users should explicitly choose to install.

Reasons why rubypick should not be a dependency of ruby:

1. If I only ever install ruby, why should a ruby switcher also be installed? 
2. rubypick's `ruby _mri_` syntax is not backwards compatible with pre-rubypick environments. This is essentially introducing new functionality in how ruby can be invoked from the shell and should be opt-in.
3. The `ruby _jruby_` functionality can be achieved without any ruby switcher, by simply running `jruby [options]...` or `jruby -S myscript [options]...`.
4. The `_jruby_` argument is ignored when a ruby process invokes ruby again: `ruby _jruby_ -e 'system("ruby","-v")'`.
5. rubypick only supports /usr/bin/ruby-mri and /usr/bin/ruby-jruby. It does not allow configuration of additional rubies (ex: Rubinius, MagLev, MRuby, etc), multiple Ruby versions (ex: 1.8, 1.9, 2.0, etc) or user installed rubies (/opt/rubies/).
6. There are already three major Ruby switchers that Ruby developers prefer: RVM [2], rbenv [3] and chruby [4]. Forcing a fourth ruby switcher onto Ruby developers is creating friction.
7. You cannot easily remove rubypick without bypass yum with `rpm -e --nodeps rubypick` and renaming/symlinking /usr/bin/ruby-mri to /usr/bin/ruby.
8. Replacing /usr/bin/ruby with a bash script broke Rubinius <= 2.2.0 ./configure script, which assumes /usr/bin/ruby is always an ELF executable. See bug #995925
9. rubypick has no unit-tests.

[1]: https://github.com/bkabrda/rubypick
[2]: http://rvm.io/
[3]: https://github.com/sstephenson/rbenv
[4]: https://github.com/postmodern/chruby

Comment 1 Vít Ondruch 2014-04-22 08:32:41 UTC
(In reply to postmodern from comment #0)
> Currently, the ruby package install a /usr/bin/ruby-mri executable and also
> requires /usr/bin/ruby, which the rubypick package provides. This causes the
> rubypick switcher script [1] to always be installed along with ruby.
> Instead, rubypick should be an optional dependency which users should
> explicitly choose to install.
> 
> Reasons why rubypick should not be a dependency of ruby:
> 
> 1. If I only ever install ruby, why should a ruby switcher also be
> installed? 
> 2. rubypick's `ruby _mri_` syntax is not backwards compatible with
> pre-rubypick environments. This is essentially introducing new functionality
> in how ruby can be invoked from the shell and should be opt-in.

This functionality was designed to be backward compatible. Does it breaks something for you, when you are saying it is not backward compatible?

> 3. The `ruby _jruby_` functionality can be achieved without any ruby
> switcher, by simply running `jruby [options]...` or `jruby -S myscript
> [options]...`.

Of course. The same way you can call ruby-mri directly, bypassing rubypick. But hopefully, one day we will be able to install jruby without MRI and execute it just by calling `ruby`. It should be transparent to the users.

> 4. The `_jruby_` argument is ignored when a ruby process invokes ruby again:
> `ruby _jruby_ -e 'system("ruby","-v")'`.

Yes, why not? It is like complaining that `ruby _jruby_ -e 'system("bash","-v")'` executes bash. It does what you say it to do. Anyway, if you want your example to behave the way you want, you should use environment variable RUBYPICK=_jruby_ instead of parameter.

> 5. rubypick only supports /usr/bin/ruby-mri and /usr/bin/ruby-jruby. It does
> not allow configuration of additional rubies (ex: Rubinius, MagLev, MRuby,
> etc), multiple Ruby versions (ex: 1.8, 1.9, 2.0, etc) or user installed
> rubies (/opt/rubies/).

We are open to suggestions and PR. We are also thinking about integration of rubypick with SCLs.

> 6. There are already three major Ruby switchers that Ruby developers prefer:
> RVM [2], rbenv [3] and chruby [4]. Forcing a fourth ruby switcher onto Ruby
> developers is creating friction.

They are not rubyswitchers. They are ruby versions managers. They have completely different target audience then rubypick. If you want something comparable to rubypick, you should think about environment modules or alternatives.

> 7. You cannot easily remove rubypick without bypass yum with `rpm -e
> --nodeps rubypick` and renaming/symlinking /usr/bin/ruby-mri to
> /usr/bin/ruby.

That is true. There is no way around as long as RPM can't better express weak dependencies. This shoulb be resolved around F22 hopefully.

> 8. Replacing /usr/bin/ruby with a bash script broke Rubinius <= 2.2.0
> ./configure script, which assumes /usr/bin/ruby is always an ELF executable.
> See bug #995925

Please consider reporting error to Rubinius.

> 9. rubypick has no unit-tests.

That is unfortunately true. Somebody has to write them. PR is welcome.
 
> [1]: https://github.com/bkabrda/rubypick
> [2]: http://rvm.io/
> [3]: https://github.com/sstephenson/rbenv
> [4]: https://github.com/postmodern/chruby

Comment 2 postmodern 2014-04-22 21:16:48 UTC
(In reply to Vít Ondruch from comment #1)
> (In reply to postmodern from comment #0)
> > Currently, the ruby package install a /usr/bin/ruby-mri executable and also
> > requires /usr/bin/ruby, which the rubypick package provides. This causes the
> > rubypick switcher script [1] to always be installed along with ruby.
> > Instead, rubypick should be an optional dependency which users should
> > explicitly choose to install.
> > 
> > Reasons why rubypick should not be a dependency of ruby:
> > 
> > 1. If I only ever install ruby, why should a ruby switcher also be
> > installed? 

You forgot to answer this first one. Perhaps rubypick should be a dependency of jruby, instead of ruby?

> > 2. rubypick's `ruby _mri_` syntax is not backwards compatible with
> > pre-rubypick environments. This is essentially introducing new functionality
> > in how ruby can be invoked from the shell and should be opt-in.
> 
> This functionality was designed to be backward compatible. Does it breaks
> something for you, when you are saying it is not backward compatible?

It is not backwards compatible because it introduces new argument syntax:

/opt/rubies/ruby-2.0.0-p451/bin/ruby _mri_
/opt/rubies/ruby-2.0.0-p451/bin/ruby: No such file or directory -- _mri_ (LoadError)

> 
> > 3. The `ruby _jruby_` functionality can be achieved without any ruby
> > switcher, by simply running `jruby [options]...` or `jruby -S myscript
> > [options]...`.
> 
> Of course. The same way you can call ruby-mri directly, bypassing rubypick.
> But hopefully, one day we will be able to install jruby without MRI and
> execute it just by calling `ruby`. It should be transparent to the users.

Could this be achieved by a post-install script adding a ruby -> jruby symlink?

> 
> > 4. The `_jruby_` argument is ignored when a ruby process invokes ruby again:
> > `ruby _jruby_ -e 'system("ruby","-v")'`.
> 
> Yes, why not? It is like complaining that `ruby _jruby_ -e
> 'system("bash","-v")'` executes bash. It does what you say it to do. Anyway,
> if you want your example to behave the way you want, you should use
> environment variable RUBYPICK=_jruby_ instead of parameter.

It's a buggy feature that can surprise the user. I already submitted two issues about how this might be fixed.

> 
> > 5. rubypick only supports /usr/bin/ruby-mri and /usr/bin/ruby-jruby. It does
> > not allow configuration of additional rubies (ex: Rubinius, MagLev, MRuby,
> > etc), multiple Ruby versions (ex: 1.8, 1.9, 2.0, etc) or user installed
> > rubies (/opt/rubies/).
> 
> We are open to suggestions and PR. We are also thinking about integration of
> rubypick with SCLs.

From what little I've read about SCLs, I think they are a better long-term solution than rubypick. If the user wants to switch between multiple rubies in /opt/rubies, chruby is a better solution. 

> 
> > 6. There are already three major Ruby switchers that Ruby developers prefer:
> > RVM [2], rbenv [3] and chruby [4]. Forcing a fourth ruby switcher onto Ruby
> > developers is creating friction.
> 
> They are not rubyswitchers. They are ruby versions managers. They have
> completely different target audience then rubypick. If you want something
> comparable to rubypick, you should think about environment modules or
> alternatives.

Actually, chruby is a ruby switcher, as it does not handle installing or updating rubies. It merely modifies $PATH based on the selected ruby from $RUBIES. I also wondered why Fedora didn't use alternatives for this? 

> 
> > 7. You cannot easily remove rubypick without bypass yum with `rpm -e
> > --nodeps rubypick` and renaming/symlinking /usr/bin/ruby-mri to
> > /usr/bin/ruby.
> 
> That is true. There is no way around as long as RPM can't better express
> weak dependencies. This shoulb be resolved around F22 hopefully.

Good news!

> > 8. Replacing /usr/bin/ruby with a bash script broke Rubinius <= 2.2.0
> > ./configure script, which assumes /usr/bin/ruby is always an ELF executable.
> > See bug #995925
> 
> Please consider reporting error to Rubinius.

I did report this upstream. It appears to have been fixed in 2.2.6. Rubinius <= 2.2.5 still breaks on rubypick.
 
> > 9. rubypick has no unit-tests.
> 
> That is unfortunately true. Somebody has to write them. PR is welcome.

I don't think it is responsible to install software along with ruby, that lacks unit tests. Until someone does write unit-tests, rubypick should be downgraded to an optional dependency.

>  
> > [1]: https://github.com/bkabrda/rubypick
> > [2]: http://rvm.io/
> > [3]: https://github.com/sstephenson/rbenv
> > [4]: https://github.com/postmodern/chruby

Comment 3 Vít Ondruch 2014-04-24 05:51:48 UTC
(In reply to postmodern from comment #2)
> (In reply to Vít Ondruch from comment #1)
> > (In reply to postmodern from comment #0)
> > > Currently, the ruby package install a /usr/bin/ruby-mri executable and also
> > > requires /usr/bin/ruby, which the rubypick package provides. This causes the
> > > rubypick switcher script [1] to always be installed along with ruby.
> > > Instead, rubypick should be an optional dependency which users should
> > > explicitly choose to install.
> > > 
> > > Reasons why rubypick should not be a dependency of ruby:
> > > 
> > > 1. If I only ever install ruby, why should a ruby switcher also be
> > > installed? 
> 
> You forgot to answer this first one. Perhaps rubypick should be a dependency
> of jruby, instead of ruby?

There has to be 'ruby' executable. If we don't have 'ruby' executable and our users will be forced to use 'ruby-mri' instead, it won't help anything. There will be people complaining I am running `ruby-mri -e 'system("ruby","-v")'`but it fails to find ruby executable.

It would be nice if you can uninstall rubypick, but again, this is not possible due to lack of RPM expressiveness. This will be hopefully possible in F22.
 
> > > 2. rubypick's `ruby _mri_` syntax is not backwards compatible with
> > > pre-rubypick environments. This is essentially introducing new functionality
> > > in how ruby can be invoked from the shell and should be opt-in.
> > 
> > This functionality was designed to be backward compatible. Does it breaks
> > something for you, when you are saying it is not backward compatible?
> 
> It is not backwards compatible because it introduces new argument syntax:
> 
> /opt/rubies/ruby-2.0.0-p451/bin/ruby _mri_
> /opt/rubies/ruby-2.0.0-p451/bin/ruby: No such file or directory -- _mri_
> (LoadError)

New argument is new argument. It is like arguing that Ruby 1.8 does not support --disable-gems flag. This is Fedora feature. It does not collide with anything to me knowledge.

> > 
> > > 3. The `ruby _jruby_` functionality can be achieved without any ruby
> > > switcher, by simply running `jruby [options]...` or `jruby -S myscript
> > > [options]...`.
> > 
> > Of course. The same way you can call ruby-mri directly, bypassing rubypick.
> > But hopefully, one day we will be able to install jruby without MRI and
> > execute it just by calling `ruby`. It should be transparent to the users.
> 
> Could this be achieved by a post-install script adding a ruby -> jruby
> symlink?

Symlink can link just to one interpreter. If you have installed MRI and JRuby and possibly other interpreters on single system, how it would work?

 
> > > 4. The `_jruby_` argument is ignored when a ruby process invokes ruby again:
> > > `ruby _jruby_ -e 'system("ruby","-v")'`.
> > 
> > Yes, why not? It is like complaining that `ruby _jruby_ -e
> > 'system("bash","-v")'` executes bash. It does what you say it to do. Anyway,
> > if you want your example to behave the way you want, you should use
> > environment variable RUBYPICK=_jruby_ instead of parameter.
> 
> It's a buggy feature that can surprise the user. I already submitted two
> issues about how this might be fixed.

Look, if you start using `ruby _jruby_`, you are probably not average user. In that case, you are expected to be aware of consequences of you actions. Yes, it might be confusing from time to time, I agree.

> > 
> > > 5. rubypick only supports /usr/bin/ruby-mri and /usr/bin/ruby-jruby. It does
> > > not allow configuration of additional rubies (ex: Rubinius, MagLev, MRuby,
> > > etc), multiple Ruby versions (ex: 1.8, 1.9, 2.0, etc) or user installed
> > > rubies (/opt/rubies/).
> > 
> > We are open to suggestions and PR. We are also thinking about integration of
> > rubypick with SCLs.
> 
> From what little I've read about SCLs, I think they are a better long-term
> solution than rubypick. If the user wants to switch between multiple rubies
> in /opt/rubies, chruby is a better solution.

chruby is doing some assumptions as well as rubypick. chruby might be better for some scenarios. For anything else, it needs configuration.

> > > 6. There are already three major Ruby switchers that Ruby developers prefer:
> > > RVM [2], rbenv [3] and chruby [4]. Forcing a fourth ruby switcher onto Ruby
> > > developers is creating friction.
> > 
> > They are not rubyswitchers. They are ruby versions managers. They have
> > completely different target audience then rubypick. If you want something
> > comparable to rubypick, you should think about environment modules or
> > alternatives.
> 
> Actually, chruby is a ruby switcher, as it does not handle installing or
> updating rubies.

Yes, chruby might be exception.

> It merely modifies $PATH based on the selected ruby from
> $RUBIES.

Modifying path is hardly enough when your system scripts are using #!/usr/bin/ruby shebang.

> I also wondered why Fedora didn't use alternatives for this? 

Because alternatives requires administrator privileges to switch from one to another alternative.

> > > 8. Replacing /usr/bin/ruby with a bash script broke Rubinius <= 2.2.0
> > > ./configure script, which assumes /usr/bin/ruby is always an ELF executable.
> > > See bug #995925
> > 
> > Please consider reporting error to Rubinius.
> 
> I did report this upstream. It appears to have been fixed in 2.2.6. Rubinius
> <= 2.2.5 still breaks on rubypick.
>  
> > > 9. rubypick has no unit-tests.
> > 
> > That is unfortunately true. Somebody has to write them. PR is welcome.
> 
> I don't think it is responsible to install software along with ruby, that
> lacks unit tests. Until someone does write unit-tests, rubypick should be
> downgraded to an optional dependency.

I acknowledge that this is how it would be in ideal world.


Note You need to log in before you can comment on or make changes to this bug.