I think you need to provide more info, how is this related to Sinatra?

@dentarg It's related in that our CI becomes red on each commit, and we have a harder time figuring out which of our changes are good/bad. In order to make the signal value improve, we could perhaps make ruby-head not a required check in CI.

(Thanks a lot for asking!)

The therubyracer gem's last commit was 2018, and perhaps it's an "ailing project".

The therubyracer gem's last commit was 2018, and perhaps it's an "ailing project".

Exactly, therubyracer, besides having the last commit in 2018, is pretty much abandoned, being miniracer the alternative (check rubyjs/therubyracer#462)

But why do we install therubyracer in the first place? The only reason I found is because we support less and the gem requires therubyracer to work even if it isn't defined in its gemspec, you can check the requirement directly in the code https://github.com/cowboyd/less.rb/blob/8d94cdd06842121550e957c545420a2460934f52/lib/less/java_script/v8_context.rb#L4

# Sinatra tests output when run without `therubyracer` installed

[WARNING] Please install gem 'therubyracer' to use Less.
cannot load such file -- v8: skipping less tests

The less gem hasn't been updated since 2015 and is definitely dead.

I don't like deprecating stuff for the sake of doing it but, does it make sense to keep having these dependencies and supporting less?

@epergo Good find, thanks for sleuthing 🔍 !

Could less support become a plugin/its own gem? Or, simpler, being dropped?

In order to move forward, I tried things in #1716

Could less support become a plugin/its own gem? Or, simpler, being dropped?

Here I'm more inclined to just drop it. If anyone want to use less with Sinatra can always install the current 2.1.0 version.

My 2 cents

@olleolleolle thanks for clarifying, I didn’t realize that with “our” you meant Sinatra :) I agree with dropping the support

IMHO, the Gemfile requirement for therubyracer is unresolveable for the average person on macOS 11.6, especially under Ruby 3.0.2. While libv8 can be compiled with either clang++ or GCC, therubyracer simply fails to compile under any reasonable scenario regardless of what flags (a non-expert C person) tries. This is clearly a bug in therubyracer, and not in Sinatra per se, but depending on a gem that can't be compiled by the average Sinatra developer seems like a bad idea.

Having said that, even with both node and v8 installed via homebrew, removing therubyracer from the various Gemfiles in the repository allows the bundle to install, but none of the spec suites in the main or contrib repository complete successfully. I also managed to manually compile libv8 and therubyracer with:

# from the root of the sinatra main branch
bundle config --local --with-cxx=clang++ --with-system-v8
bundle config --local --with-v8-dir=/usr/local/opt/v8@3.15
bundle install

with the unmodified Sinatra Gemfile, but with or without therubyracer installed the Sinatra specs still fail, usually on a rack/protection LoadError.

I'm not sure how to pull the dependencies out (why exactly are we depending on it, rather than just selecting from an available Node or V8 installation anyway?) since I can't get the Sinatra specs to pass with or without therubyracer, but I definitely think it ought to be removed if it's unmaintained and open to vulnerabilities.

On a related note, I'm not sure how Rails is auto-detecting the presence of a native V8 or Node runtime, but it's worth pointing out that they are doing so, and recommending the use of the mini_racer gem on systems that don't have a pre-existing Javascript runtime.

@todd-a-jacobs 👋 Hi, and thanks for thinking about this. I created the #1718 issue, which is about dropping Less, which is no longer maintained either, and which was the only thing in the stack which required the dependency 'therubyracer'.

In order to make the signal value improve, we could perhaps make ruby-head not a required check in CI.

This makes sense to me, because ruby-head is a moving target. Things are added, removed, and otherwise in flux on ruby-head all year long, and while it's often useful to treat failing unstable branches as advisories, it seems like failing CI over "breaking changes" in a future version that haven't stablized or may not even remain in the eventually-released version is just noise.

I'm not a committer on this project, but I'd be strongly in favor of treating any tests against ruby-head as purely advisory. As an example, this could be done by changing Travis CI to run ruby-head as a separate job with allow_failures against ruby-head enabled. This way, you can still test against ruby-head for informational purposes without necessarily having to exclude it altogether, or failing the whole CI run because of something that may never actually be a real problem.

Alright, that change has been merged in #1718!