Explicit dependency on Racc

[voxik]

Since Nokogiri depends on Racc in runtime, it would be nice if the dependency was explicitly specified. I know that Racc is part of Ruby StdLib as default gem, OTOH one day Racc will release incompatible version and Nokogiri won't be usable with certain older versions of Ruby without older gemified version of Racc.

[flavorjones]

@voxik Thanks for pointing this out! As you mentioned, because it's in the Ruby stdlib, we don't today need to explicitly require it as a dependency.

I think I'd prefer to wait until a problem arises due to a backwards-incompatible difference between the Racc version in stdlib and what's generated in the Nokogiri code base. If it happens, I'd be happy to cut a patch release specifying a dependency on a particular version of Racc. In the meantime, we have CI pipelines running against all supported Ruby versions to detect any brokenness around Racc behavior.

I'm curious if you think we should also declare a runtime dependency on yaml, psych, strscan, and stringio, which are also gems in the stdlib?

[voxik]

I'm curious if you think we should also declare a runtime dependency on yaml, psych, strscan, and stringio, which are also gems in the stdlib?

I really think every project should properly specify their dependencies, so this applies to every gem. You can never know who else is using any of these libraries and might want to use some specific version. E.g. use yaml with syck instead of psych. These are things out of your control. Also, for example, now I have fix several packages failing in Fedora due to e2mmap removal from Ruby StdLib. If the projects specified this dependency explicitly, it would be much easier to track the possible issues.

[tenderlove]

How does this help nokogiri users as opposed to package maintainers? I am sure it will cause users to spend more time resolving gems and downloading packages, so what do they get out of it?

I'm not super opposed to this, but I'd really like to know the upside for actual users. Thanks.

[voxik]

Think of it this way. If there is gem which specifies s.add_dependency "racc", "1.4.6" and it is mixed with Nokogiri in one app, what will be the result? What will tell the developer/user, that this is probably not good idea?

Or another case. If next Ruby is released with incompatible version of Racc 2.x, all old versions of Nokogiri will be broken just because it does not specify its dependencies properly. Some new "emergency" release might fix this, but you can't fix the old releases.

Also, if Ruby decides to drop racc, all Nokogiri versions will be broken (unnoticeably). Or Ruby will be forced to carry racc around although it is obsolete.

It seems to me that the trading "users to spend more time resolving gems and downloading packages" for possibly hard to debug bugs is not the best tradeoff. Not mentioning that so far the racc is still part of StdLib, so I am not sure where the "downloading packages" part comes from (to be precise, this applies to Ruby 2.7, where the racc was gemified, so I might be wrong for older releases). Also the "resolving gems" part is arguable, because these days, the versions are typically resolved in Gemfile.lock, so there is not resolving every time the app is running.

[flavorjones]

@voxik I'm open to making this change. Would you be interested in drafting a pull request that we can collaborate on?

[wlipa]

Just wanted to note that this change adds a new gem with native extensions that need to be built.

Fetching racc 1.5.2
Installing racc 1.5.2 with native extensions

[flavorjones]

@wlipa Thanks for commenting. I've tried to reproduce this with Ruby 2.7 and Ruby 3.0 and cannot:

# ruby 2.7
juno ruby-2.7.2 go1.14.6 (master)
nokogiri $ gem uninstall racc nokogiri
Gem 'nokogiri' is not installed
Gem racc-1.4.16 cannot be uninstalled because it is a default gem

Select gem to uninstall:
 1. racc-1.5.1
 2. racc-1.5.2
 3. All versions
> 3
Successfully uninstalled racc-1.5.1
Successfully uninstalled racc-1.5.2

juno ruby-2.7.2 go1.14.6 (master)
nokogiri $ gem install nokogiri
Fetching nokogiri-1.11.0-x86_64-linux.gem
Successfully installed nokogiri-1.11.0-x86_64-linux
1 gem installed

# ruby 3.0
nokogiri $ gem uninstall racc nokogiri
Remove executables:
	nokogiri

in addition to the gem? [Yn]  y
Removing nokogiri
Successfully uninstalled nokogiri-1.11.0.rc3-x86_64-linux
Gem racc-1.5.1 cannot be uninstalled because it is a default gem
Successfully uninstalled racc-1.5.2

juno ruby-3.0.0 go1.14.6 (master)
nokogiri $ gem install nokogiri
Fetching nokogiri-1.11.0-x86_64-linux.gem
Successfully installed nokogiri-1.11.0-x86_64-linux
1 gem installed

This is because racc is a default gem in both versions of Ruby.

If you have more questions, I'd prefer to open a new issue for it, if you wouldn't mind -- with all the information we ask for in the template about your system. Thanks!

[flavorjones]

Ah, @wlipa I'm guessing you're running Ruby 2.6 or earlier, which doesn't declare Racc as a gem. In that case, yes, this is a known side effect of the new explicit dependency.

[wlipa]

I'm using 2.7.2. It was via a 'bundle update' command, not invoking 'gem install' directly. I'll open another issue for it.

$ ruby --version
ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin20]