This is because the Accumulo shell is a custom built shell? If so, we had one of those once and replaced it with the IRB based one. We didn't settle on JRuby right away but, at the time, the consensus was we didn't want to be in the business of maintaining yet another REPL when specialist open source communities have already done that. Why has this changed? Has it?
Why is the Accumulo shell easier to script with? Does it have control flow constructs? Variable assignment? Or is it easier somehow because it does not have those things? Even the system shell has those. Hmm... Are we saying that any control flow or variables/substitution should be done by calling our shell from a bash or sh script? Wouldn't that be super slow given Java's startup time for every invocation of our shell? A bit like trying to script the AWS command line utilities, which is excruciating. I can see why a custom shell built with Java would easier to test where the rest of the project is using Surefire/JUnit. That's a developer convenience concern though, not a user convenience one. On Wed, May 13, 2015 at 10:41 AM, Sean Busbey <bus...@cloudera.com> wrote: > Pros: > > * It's easier to test and maintain > * it's easier to script with > * its interactive mode "feels" mode focused on the task of interacting with > a cluster to me (maybe this is just acting like a psql or mysql shell) > > Cons > > * adding custom commands requires knowing java > > -- > Sean > On May 13, 2015 12:31 PM, "Andrew Purtell" <apurt...@apache.org> wrote: > > > Why is the Accumulo shell superior? > > > > Is it scriptable? > > > > > > On Wed, May 13, 2015 at 10:28 AM, Sean Busbey <bus...@cloudera.com> > wrote: > > > > > I would love to rip out the JRuby shell entirely and make something > > closer > > > to the Accumulo shell, but I expect that will > > > > > > 1) be way more work > > > > > > 2) be even less compatible for those that rely on customizations. > > > > > > I figured given time we could get a preview "user shell" (rather than > > > "power shell" via irb) together in 2.0 and aim for default in 3.0. > > > > > > -- > > > Sean > > > On May 13, 2015 12:19 PM, "Stack" <st...@duboce.net> wrote: > > > > > > > Nice writeup Sean. > > > > > > > > Yeah, +1 to new jruby in hbase 2.0. We'd need to be careful license > is > > > > still amenable and hopefully jruby 9k will be slimmer than jruby > 1.7+. > > > > > > > > But if we are going to do a significant shell refactor for hbase 2.0, > > > > should we consider doing something more radical; e.g. a new shell? If > > > > interest, could start up a new thread so don't distract from this > one. > > > > > > > > St.Ack > > > > > > > > > > > > > > > > > > > > On Wed, May 13, 2015 at 9:22 AM, Sean Busbey <bus...@cloudera.com> > > > wrote: > > > > > > > > > Hi folks! > > > > > > > > > > If you weren't aware, our current shell relies on Ruby, > specifically > > > the > > > > > REPL program IRB from JRuby. When we launched 1.0 we were on JRuby > > 1.6 > > > > with > > > > > defaults, which means we're stuck on Ruby 1.8. > > > > > > > > > > For those that don't already know, Ruby 1.8 is super old and has > been > > > > > walking off into the sunset for a few years now. Most (but not > all!) > > > > formal > > > > > support systems for running Ruby have EOLed 1.8 and there are > > numerous > > > > > known issues with it. > > > > > > > > > > Right now there's an open ticket to get us on JRuby 1.7 so that our > > > shell > > > > > can work on PPC systems[1]. That version of JRuby defaults to Ruby > > 1.9 > > > > but > > > > > can be run in Ruby 1.8 mode. There are some implementation details > > > > > outstanding, but I'm hoping that ticket can work out such that it > can > > > > land > > > > > in branch-1. > > > > > > > > > > For HBase 2.0, I'd like us to plan for a little farther out in the > > > future > > > > > than just updating to Ruby 1.9 (though that would be a fine > > incremental > > > > > step with some non-trivial work attached). The "current" version of > > > Ruby > > > > is > > > > > 2.2. Much like the move from 1.8 -> 1.9 it is not backwards > > compatible. > > > > > > > > > > JRuby's next major maintenance release line is "version 9000"[2] > and > > it > > > > > will start out *only* supporting Ruby 2.2. Right now JRuby 9000 is > in > > > its > > > > > second "preview" release. They still have a few feature complete > > items > > > to > > > > > address before they hit their first GA release. > > > > > > > > > > I'd like us to move to Ruby 2.2 via JRuby 9000 for HBase 2.0. This > > > will > > > > > cause operator pain to folks with advanced scripts based on Ruby > 1.8, > > > but > > > > > it should allow us to update versions to avoid e.g. perf, > > correctness, > > > > and > > > > > security issues much more easily over the lifetime of 2.0. > > > > > > > > > > What do folks think? Would JRuby 9000 need to hit a GA release > prior > > to > > > > > HBase 2.0 getting released for us to adopt it? Or would it only > need > > > > enough > > > > > of Ruby 2.2 to run our current shell? > > > > > > > > > > > > > > > [1]: https://issues.apache.org/jira/browse/HBASE-13338 > > > > > [2]: > http://www.slideshare.net/CharlesNutter/over-9000-jruby-in-2015 > > > > > > > > > > -- > > > > > Sean > > > > > > > > > > > > > > > > > > > > -- > > Best regards, > > > > - Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > (via Tom White) > > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
