It looks like in a recent RubyGems it became possible to have it install
all scripts with “j” prefixes. “jrake”, “jrails”, etc. It appears to be
broken in 1.3.1 when defaults are specified, but Eric H. has been
informed about that and it may get fixed.
The justification is similar to that for other impls…macruby installs
macrake, ruby1.9 installs rake1.9, and so on. In that light, I think I
support the “j” prefix more now than I used to. But I don’t think we can
break existing behavior.
So I guess there’s a decision here. We could basically flip a bit with
the next upgrade (RubyGems 1.3.2 in JRuby 1.1.6?) to start installing
everything with “j” prefix. Or we could force it to remain the way it
is. Or we could provide a way that users can specify which behavior they
want (suggestions welcome).
So I guess there’s a decision here. We could basically flip a bit with
the next upgrade (RubyGems 1.3.2 in JRuby 1.1.6?) to start installing
everything with “j” prefix. Or we could force it to remain the way it
is. Or we could provide a way that users can specify which behavior they
want (suggestions welcome).
Please… have the j prefix… make sure there are no conflicts with
regular Ruby (i.e jem vs gem).
Can’t tell you how useful it would be to have standard ruby & jruby
installations that could co-exist without the need to mess with
environment variables.
Please… have the j prefix… make sure there are no conflicts with
regular Ruby (i.e jem vs gem).
Can’t tell you how useful it would be to have standard ruby & jruby
installations that could co-exist without the need to mess with
environment variables.
I’m sure it would be useful, but I also worry about those scripts and
users who don’t expect the “j” prefix. There’s certain to be a lot of
code out there that shells out to “ruby” or “rake” without reformatting.
I’m on the fence whether we can make “j” the default, but I don’t see
why we couldn’t provide it as a configurable bit after
unpacking/installing JRuby.
The standard reason is if you have both normal Ruby and JRuby on your
system and want to be sure you’re running the JRuby version of a given
command.
Khaled al Habache wrote:
install all scripts with "j" prefixes. "jrake", "jrails", etc. It
installing everything with "j" prefix. Or we could force it to
http://xircles.codehaus.org/manage_email
I wouldn’t mind the j prefix, but I do wonder how people who write
scripts which call these commands via things like backquote will cope?
Even though gem provides a method for calling these commands, I
wonder how many people will know it exists? Will we be hunting down
and reporting/education forevermore?
OTOH, it is very common for people who start with JRuby to get stuck
on -S at first. This would eliminate that support issue.
I am of two minds…
-Tom
On Tue, Nov 11, 2008 at 3:37 PM, Charles Oliver N. [email protected] wrote:
So I guess there’s a decision here. We could basically flip a bit with the
To unsubscribe from this list, please visit:
code out there that shells out to “ruby” or “rake” without reformatting.
I’m on the fence whether we can make “j” the default, but I don’t see
why we couldn’t provide it as a configurable bit after
unpacking/installing JRuby.
I’d be inclined to make the j prefix the default, but include a
compatibility script that did the appropriate mapping (eg gem->jem,
ruby->jruby, etc…) for those people who need it.
As long as the jruby versions of the tools and scripts are backwards
compatible at the command option level with the ruby versions, there
really shouldn’t be too much of a problem. And to be honest, those
kinds of incompatibilities concern me more than command naming.
I’ve been bitten in the ass enough times by jruby’s gem, that I would
have raised this as a feature request, had you not addressed it ahead of
me.
I do this by hand for rake and gems. It would be pretty sweet to know
when I run some of my common gem commands such as rawr or monkeybars,
that I knew I was always running the version I meant to run.
-1 on making it the default behavior, as I think that will lead to
confusion and seems a bit at odds with gem author intent.
0 (neutral) to the idea of making this behavior available as a
non-default option.
In my own work I think there is only a small subset of gem bin scripts
(like jrake) where I actually want the jruby and ruby versions to
coexist. In these cases I think it perfectly reasonable to manually
create ‘j’ symlinks to handle these myself. In the odd one-off case, as
mentioned, we can still do “jruby -S ”.
I’ve blogged about my own j?ruby coexistence strategy here: