rb-appscript: won't install on Ruby 2.2.x

[eric-hu]

When trying to install another gem (consular-iterm), it fails while trying to install rb-appscript with the following error:

ERROR:  Error installing consular-iterm:
  ERROR: Failed to build gem native extension.

    /Users/erichu/.rvm/rubies/ruby-2.2-head/bin/ruby -r ./siteconf20150729-1786-1m2j7h9.rb extconf.rb
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
  --with-opt-dir
  --with-opt-include
  --without-opt-include=${opt-dir}/include
  --with-opt-lib
  --without-opt-lib=${opt-dir}/lib
  --with-make-prog
  --without-make-prog
  --srcdir=.
  --curdir
  --ruby=/Users/erichu/.rvm/rubies/ruby-2.2-head/bin/$(RUBY_BASE_NAME)
extconf.rb:44:in `<main>': uninitialized constant Config (NameError)

extconf failed, exit code 1

There was a similar error reported for another gem and the cause is that
Ruby 2.2 changes the Config global namespace to RbConfig.

[eric-hu]

I took a crack at a pull-request to fix, but I found:

• the rb-appscript test suite hasn't been updated for Minitest (Ruby 1.9)
• there are also test failures from possible Applescript API changes
  • I ran this on OS X 10.9.5

I hit the timebox I set aside for this before I got far into the test suite, so
I don't want to sink too much more time into this. Would any of these options
be acceptable?

1. Change Config references to RbConfig (just get the install working for Ruby
   2.2.x, leave the test suite non-functional)
2. Update the test suite to run entirely with Minitest, tests that are failing will be left in that state

[mattneub]

I don't have much time right now either. How about if we just remove the tests temporarily - would that solve it?

[eric-hu]

I think it's more inviting for someone to update tests if they're in the repo but failing. Also, I just noticed that a merged pull request (#11) does the work required to fix this issue.

It'd be really nice for the Ruby community if we could get this into a separate version and added to Rubygems. I see your last comment on the other issue, if you'd like me to reach out to Hamish about transferring gem ownership, I'd be happy to.

[irons]

Building from the top of master, f6edd1e7, does succeed for me, with ruby 2.2.2, xcode 6.4, on 10.10.4. The process looks like this:

• clone appscript
• cd appscript/rb-appscript/trunk
• ruby extconf.rb
• make
• make install
• gem build ./rb-appscript.gemspec
• gem install ./rb-appscript-0.6.1.gem

[eric-hu]

It sounds like that flow works if you'd like a fork of rb-appscript to use directly in your code. Having a broken version on Rubygems means that all gems which specify rb-appscript as a dependency won't have this bug fixed though.

[mattneub]

I certainly can't deal with him (Hamish)... I've never posted anything on Rubygems and I know nothing of it; I always build rb-appscript from scratch and install by hand. I would be very happy to have you deal with doing the Rubygems end of things! (I'd be very happy to have someone take over this whole repo, quite frankly.)

So you're saying that we don't need to do anything except get an update onto Rubygems? Because if that's the case, I should close this.

[alfredo-cp]

Thanks @irons it worked like a charm. I have the same setup. ruby 2.2.2, Xcode 6.4 and OS X 10.0.5

[leonar]

rb-appscript could not work on linux, isn't it?

[eric-hu]

@leonar As I understand it, the purpose of rb-appscript is to be a wrapper around OS X API commands. OS X is based on bsd, which is unix. I don't think it makes sense on anything but OS X.

[eric-hu]

@mattneub I haven't yet reached out to Hamish, it kind of fell to the bottom of my todo list. :( Today, I found some new information which might resolve the root of this issue--that rb-appscript on RubyGems doesn't match the Ruby code in this repo.

I revisited the issue I had before with Consular, which has rb-appscript as a dependency.

Looking again for solutions, it turns out that someone has copied just the rb-appscript portion of this repo and renamed it rb-scpt, and also put it on RubyGems.

If you'd like to hand off this repo, should we start a conversation with BrendanThompson about taking over the Ruby portion?

[mattneub]

@eric-hu Thinking about it, I would say my big concerns going forward are:

• Language changes. We can't be all things to all people, but Ruby has been known to change in a way that causes breakage, so whoever maintains needs to be ready to cope. I suppose Python can do the same, though I know nothing of that. But in the Ruby case, things are made more complicated by the fact that many environments do not update their Ruby. For example, Mac OS X Yosemite is at Ruby 2.0.0, so we must continue to work in that environment. I don't feel all that much responsibility to experimenters who have moved to 2.2 in rbenv or whatever.
• The gem. It sounds to me, from what you say, like that has been solved another way. We can't impersonate Hamish and update his gem, so having a separate gem seems like the way to go.
• The C code. We depend upon C code (such as rbae.c) that is barely compiling at this point — we generate a ton of warnings. I asked Hamish if he would give this some attention and he basically blew me off (no surprise there). It would be really nice to modernize this code.

[eric-hu]

For example, Mac OS X Yosemite is at Ruby 2.0.0, so we must continue to work in that environment.

So backwards compatibility to Ruby 2.0.0 is important to this repo. That seems reasonable moving forward.

It sounds to me, from what you say, like that has been solved another way. We can't impersonate Hamish and update his gem, so having a separate gem seems like the way to go.

This has been solved for people who know to look for rb-scpt. It'd be useful for developers to be able to bundle update rb-appscript or gem update rb-appscript and just have a version that works for newer versions of Ruby. Having 2 forks of rb-appscript also means more fragmentation.

For people who want to use a gem depending on rb-appscript, the gem will have to be switched from rb-appscript to rb-scpt. The first solution I tried months ago was something along the lines of

gem 'rb-appscript', git: "mattneub/appscript"

Unfortunately, this doesn't work because the rb-appscript code in this repo is a submodule, and rubygems doesn't support git submodules. Bundler might, but Ruby Gems are supposed to specify their dependencies with .gemspec files instead of Gemfiles. I think the Ruby community would benefit a lot from having updates to rb-appscript on Rubygems again.

I've sent a message to Hamish to see if he's willing to hand off control of rb-appscript on Rubygems. After doing that, I also noticed that the Rubygems page lists the owner as null, so it may be that he deleted his account. In that case, I've heard of people contacting Rubygems to request control of an orphaned project. That could be done in this case too.

It would be really nice to modernize this code.

That seems like a nice thing to have the roadmap. It sounds like Hamish is done working on this project after maintaining it for several years, which seems fair given the work he's put in. Modernizing the code would fall to whoever is going to maintain it.

---

To recap, I'm trying to kill a few birds birds with one stone:

• Hand off: You mentioned earlier in the thread that you're looking to hand off this repo to someone else. If your thoughts on this have changed, pardon my suggestion.
• Get this code onto Rubygems: It's hard for Ruby users to benefit from newer work put into this repo because it doesn't go back into Rubygems. Rb-scpt does, but it has a discontinuity in its naming.
• Prevent more fragmentation. Updating rb-appscript to work with Ruby 2.2 was done twice: once in this repo before I filed the issue, and once in rb-scpt.
• Isolate the Ruby code: With this code being in a submodule, versions on Github can't be referenced by Rubygems. Rb-scpt already did this, which made it easier to work with all around for me.

[mattneub]

@eric-hu I believe my options are: I could make you a collaborator or I could just hand off the repo to you. Which would you prefer?

[hhas]

From my reply to Eric:

If Brendan wants it he's totally welcome to it; surprised he never asked before posting his fork. Or Matt, but I think Brendan's version has made more progress. Honestly, they should throw in together if they really care about it. He'll need to contact the RubyGems maintainers to get it transferred as I can't log into it any more.

As far as modernizing the C portion, replacement Cocoa APIs are available in NSAppleEventDescriptor (10.11+) and NSWorkspace. It's years since I did any Ruby, and never did much like it or have a clue how to build [Obj-]C extensions for it (I just nicked that bit from RubyOSA), so can't offer you any advice beyond 1. refer to SwiftAE for pointers on using the relevant Cocoa APIs

..

And yeah, for your own sanity you definitely want to dump all the other dross and focus solely on rb-appscript. Plus the usual caveat emptor about not investing more into it than you're willing to write off e.g. if Apple decides they've had enough of AppleScript and replaces it with JavaScript+XPC or something.

HTH

[eric-hu]

My email thread with Brendan follows:

---

Hi Brendan,

I found your email on your Github profile after using your rb-scpt
gem. Thank you for forking it, separating the Ruby source, and
publishing a new gem. I was trying to fix an issue with
consular-iterm and your repo helped make that possible.

I don't know what your intentions are for rb-scpt, but would you be
open to taking over rb-appscript on Rubygems? I already have
permission from Hamish: that conversation is included below. Taking
the actual gem will require talking to the people at Rubygems. I'm
happy to take care of that to see that rb-appscript gets some
continuity.

Matt Neuberg maintains a fork of Hamish's code on Github as well.
I've had this conversation with him as well, though he hasn't
expressed much interest in maintenance going forward.

What do you think? Just say the word and I'll reach out to the
Rubygems people. If it'll make the decision easier, I'm happy to help
maintain the gem and review pull requests.

Cheers,
Eric Hu

---

Hey Eric,

I could be interested. I’m not too sure I would have too much time to be able to do much though. I also prefer the name of my forked gem as well :).

However, if you’re willing to assist then I may be inclined to do it.

Thanks,

Brendan

---

@mattneub being an owner of this repo is definitely more than I would like to take on. I would consider being a collaborator, though I'm only interested in keeping continuity for rb-appscript. I currently don't have the technical skillset to maintain the other repos, nor do I have the time to learn. It looks like Brendan has forked from Hamish's code more recently than this repo, so I'd be inclined to start from his rb-scpt repo.

@BrendanThompson let's continue the conversation here so that our discussion is publicly visible.
I'm not opposed to a rename, though I'd like to see continuity for developers who currently use rb-appscript. I would like for developers to be able to gem update rb-appscript and have it just work. I'm not opposed to some kind of rename, as long as the UX isn't too painful for developers who rely on rb-appscript. One idea is to take over the rb-appscript gem on Rubygems and push an updated version that suggests pointing to rb-scpt. There may be more elegant solutions out there too, that was just off the top of my head.

@hhas I was considering taking advantage of the JavaScript api for OS X 10.10+. I haven't researched it much, it just seemed like a possibility with the execjs gem making calls to Apple JavaScriptCore.

[oliikit]

@eric-hu Do you still need assistance with updating this codebase? A gem I was using failed to bundle because my ruby version was above 2.2.0. So I'll be happy to help out.

[eric-hu]

@foxiae I reached out to Rubygems about ownership of this gem, but haven't heard back much in many months. I'm going to close this issue to simplify things for myself.

A project I occasionally collaborate on uses rb-scpt--that's been a fairly successful switchover, so I suggest using that for 2.2+.