darn, missed the inclusion of my links about the pain around moving Ruby 1.8 -> 1.9. Also "well documented" is relative. ;)
[2]: http://nerds.airbnb.com/upgrading-from-ree-187-to-ruby-193/ http://www.darkridge.com/~jpr5/2012/10/03/ruby-1.8.7-1.9.3-migration/ On Thu, Aug 14, 2014 at 3:44 PM, Sean Busbey <bus...@cloudera.com> wrote: > Responses inline > > > On Thu, Aug 14, 2014 at 3:16 PM, Jonathan Hsieh <j...@cloudera.com> wrote: > >> I've always found working with the jruby part of the hbase shell jarring >> because many of the hbase commands don't interact "natively" with jruby >> constructs. Some work was done [1] [2] to make it a little better but it >> is in that uncanny half-there half-not-there state. >> >> > Yes, the tension caused by both trying to be a shell specific to HBase and > IRB is part of what I'd like to get rid of. > > > >> On Thu, Aug 14, 2014 at 11:53 AM, Sean Busbey <bus...@cloudera.com> >> wrote: >> >> > Hiya Folks! >> > >> > Right now, the HBase shell relies on an old version of JRuby (1.6, last >> > released ~2 years ago) and a very old version of Ruby (1.8). >> > >> > I'd like to start working towards refactoring the shell. Updating some >> of >> > our underlying libraries will make it easier to fix up some of our low >> > hanging improvements (start up latency, utf8 support). >> > >> > This got me wondering about what the bounds of changing are (esp for >> > master). >> > >> > 1) How common is making use of the fact that our shell is actually and >> IRB >> > session? Do we want to keep encouraging that for users? Could we change >> the >> > focus of the IRB version to be developers of HBase? Could we just make a >> > HBase client gem and provide instructions for using it in IRB? >> > >> > >> Most admin work and much "repair" work happens in the shell. >> >> If a gem makes it super easy for folks to get started with hbase that >> sounds good. It does seem we'd need to haev a gem for each major >> version's >> shelll to maintain compatibility if the gem is hosted separately from the >> hbase release though, no? >> >> > We could publish the gem as a part of our release process. Avro does this > now for its Ruby support. > > We could also have a copy of the gem included in our binary release > somewhere for local installs. > > > >> >> > 2) However extensive our keeping IRB is, do we need to keep the same >> Ruby >> > compatibility? Spanning Ruby 1.8 and 1.9 is a pain, but possible. (I >> know >> > very few people still using 1.8 though) When Ruby 2 support lands >> > supporting either of those won't be possible, because at that point >> JRuby >> > will only support Ruby 2.1[1]. >> > >> >> I have a slight preference for keeping modern. >> > > Me too, but what does that mean for backports? > > Ruby 1.9 to 2.1 updates are supposedly smooth, but that's cold comfort to > the ops person who discovers they have to update their hbase maintenance > scripts because they land in a corner case. > > Ruby 1.8 -> later updates will be more painful. The pain is well > documented[2], but only particularly relevant if people are relying on the > "run a ruby script" functionality. > > > >> > >> > 4) Lacking #2, what do we want to ensure keeps working the same? >> Existing >> > shell commands in the exact form they have now? Table variables (as >> opposed >> > to setting a "current table" context for the shell session)? >> > >> > I have a preference for a more ruby-esque and more oo style of api for >> the >> shell. Today it is a frankenshell that is partially oo ruby style, and >> partially procedural sql-shell-style. I'd even consider a new "user >> shell" >> that is parallel to the current "hacker" shell, with the goal >> marginalizing >> the current shell for low level repair work. >> >> >> > So the oo-style shell would be the "hacker shell" and the "user shell" > would be a more traditional procedural shell? Or do you mean the reverse? > > I'm having trouble thinking of an example of a product with a > non-procedural user facing shell. > > -- > Sean > -- Sean
