Project

General

Profile

Actions

Bug #1728

closed

gem installed binaries don't honor program-suffix

Added by docwhat (Christian Höltje) over 14 years ago. Updated almost 13 years ago.

Status:
Rejected
Target version:
-
ruby -v:
ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-darwin9.7.0]
Backport:
[ruby-core:24145]

Description

=begin
What happens:

  • Compile and Install ruby using ./configure --program-suffix=-foobar
  • Install a gem that installs a binary: gem install ZenTest
  • Notice that the binaries created do not have the program-suffix: ls autotest unit_diff multi_ruby zentest

What I expected:

  • The binaries created by the gem should have the suffix -foobar: ls autotest-foobar unit_diff-foobar multi_ruby-foobar zentest-foobar

Ciao!
=end

Actions #1

Updated by drbrain (Eric Hodel) over 14 years ago

  • Status changed from Open to Rejected
  • Assignee set to drbrain (Eric Hodel)

=begin
Use gem install --format-executable.

You can make this the default by setting in ~/.gemrc

install: --format-executable
update: --format-executable
=end

Actions #2

Updated by docwhat (Christian Höltje) over 14 years ago

=begin
Why isn't that the default, then?
=end

Actions #3

Updated by rue (Eero Saynatkari) over 14 years ago

=begin
Excerpts from rubymine message of Tue Jul 07 15:42:01 +0300 2009:

Issue #1728 has been updated by Christian Höltje.

Why isn't that the default, then?

Personally, I would expect the suffix to only affect the
programs installed by that script, not "child" programs
thereof.

I think the current solution is correct, although it would
not hurt if the Gem option were a bit more prominent. I am
not very well versed in such Gem "internals," so I cannot
say whether it is a well-known flag.

Eero

Magic is insufficiently advanced technology.

=end

Actions #4

Updated by docwhat (Christian Höltje) over 14 years ago

=begin
Eero said in comment #3:

Personally, I would expect the suffix to only affect the
programs installed by that script, not "child" programs
thereof.

I think the default should cause the least amount of confusion possible.

The most common use-case for --program-suffix is if you install multiple versions of ruby. In that case, making --format-executable the default makes lots of sense. Otherwise when you install a gem with binaries you won't know which version you're running!

What would the use-case be for using --program-suffix and not having format-executable be the default?

The closest I can think of is someone using some distribution that has ruby1.8 as the default and ruby1.9 with --program-suffix. A user might become confused if they only install ruby1.9... but that is really the distro's problem to educate the user -- they already have to explain why there isn't a "ruby" command (it's actually "ruby1.9"); having to explain why "gem1.9 install ZenTest" creates "autotest1.9" instead of "autotest" isn't that big a deal.

Plus, we could have gem actually print a message saying what it is doing in this case.

Ciao!
=end

Actions #5

Updated by docwhat (Christian Höltje) over 14 years ago

=begin
I talked with a friend and I realized I'm not explaining this very well. Let me try again.

The reason --format-executable should default to on is because the binaries created by "gem" have the name of the "ruby" tied to that version of "gem".

Here's two uses cases in full:
----use case 1-----------------------
I install ruby 1.8.

I use "./configure" when compiling it.
The binaries are in /usr/bin/ and do not have a suffix.

I decide I want to work on ruby 1.9.1 as well.
I use "./configure --program-suffix=19" when compiling it.
The binaries are also in /usr/bin but all end with "19", such as "/usr/bin/ruby19".

Lets say I ZenTest for 1.8:
$ gem install ZenTest

This creates /usr/bin/autotest. This executable is intimately tied to ruby 1.8; it begins with "#!/usr/bin/ruby -ws" -- it cannot be used for ruby 1.9 (yet) because the libraries are not installed in ruby 1.9 and the executable it points to is the 1.8 executable.

Now lets say I want to install autotest for ruby 1.9:
$ gem19 install ZenTest

By default, no new binaries are created since they already exists.

The executable /usr/bin/autotest is still tied to ruby 1.8.

This causes confusion by the user; they just installed autotest for ruby 1.9 but it still is running ruby 1.8.

----use case 2-----------------------
My system administrator installs ruby 1.8 using "./configure" with no arguments.
My system administrator installs ruby 1.9.1 using "./configure --program-suffix=19"

I (a non-system-administrator) wants to install ZenTest for both:
$ gem install ZenTest
[output showing it is installed to ~/.gem]
$ gem19 install ZenTest
[output showing it is installed to ~/.gem]

So now I have two "autotest" binaries:
~/.gem/ruby/1.8/bin/autotest
and
~/.gem/ruby/1.9.1/bin/autotest

If my PATH includes both, then which "autotest" I get depends on my PATH order. The only way I can distinguish between the two executables is by changing my PATH on the fly. Not very useful if I want to be able to easily switch between both versions to verify it works in both versions of Ruby.

I think that without --format-executable as a default, this is too confusing for a normal user.

I agree that a --no-format-executable option should be kept around, though. Choice is good.

Ciao!

=end

Actions #6

Updated by drbrain (Eric Hodel) over 14 years ago

=begin
Can this discussion be moved to the rubygems-developers mailing list? It's the best place to discuss it.

http://rubyforge.org/mailman/listinfo/rubygems-developers
=end

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0