allow newer nokogumbo?

[jrochkind]

linkedddata depends on the gem nokogumbo, at "~> 1.5". https://github.com/ruby-rdf/linkeddata/blob/develop/linkeddata.gemspec#L45

nokogumbo released a 2.0.0 in October 2018, but no app depending upon linkeddata can use them, because it insists on only 1.x.

Would it be possible to update linkeddata to allow nokogumbo 2.x? Possibly in addition to 1.x as well.

Here are the nokogumbo 2.0 release notes . It looks like there are few if any significant backwards incompat changes, so it's possible linkeddata would just work with nokogumbo 2.x as well as 1.x.

[gkellogg]

Sorry to have missed this, it affects a couple of gems. I’ll update them too be more permissive. For the 3.2 release, I’m doing a more general dependence update and I’ll require 2.0 of Nokogumbo along with other gem updates.

[jrochkind]

Cool thanks. Based on the nokogumbo release notes, you might be able to get away with allowing either 1.x or 2.x of nokogumbo, instead of requiring 2.x only (and forcing dependent apps to upgrade), but I'm not totally sure, maybe not.

[jrochkind]

Actually, I'm also not certain why you are depending on nokogumbo at all? I'm a bit new to what nokogumbo is, but it's descirbed as "A Nokogiri interface to the Gumbo HTML5 parser", and the example code in it's readme show doing: Nokogiri.HTML5 and Nokogiri::HTML5 -- it looks like it adds those HTML5 methods onto the Nokogiri constant from the nokogiri gem. nokogumbo does depend on the nokogiri gem.

But searching through the sourcecode on linkeddata... I'm not sure you're using those HTML5 methods that nokogumbo adds to nokogiri? I can't find em?

Is it possible that you don't need to depend on nokogumbo at all, just nokogiri?

The README describes even nokogiri as a "soft dependency", but this isn't exactly true, it's in the gemspec as a normal dependency, the linkeddata can't be used without nokogiri being installed.

Sorry if i'm missing something! This is of interest to me, because I'm not even using linkeddata myself directly, I'm using a gem (qa) which has linkeddata as a dependency, and I'm not even necessarily using linkeddata-relevant functions of qa, but by using it it's whole dependency tree gets brought into my app, so I'm interested in if there's a way to minimize (and/or make more liberal) linkeddatas dependencies.

[gkellogg]

The linkeddata gem is a rollup which includes all of the other Ruby RDF gems. Among them are rdf-rdfa, rdf-microdata, and json-ld, which all do HTML processing. Since Nokogiri doesn't properly handle HTML5, we use Nokogumbo, if available.

You can, of course, just include the specific RDF gems you need, but we include the Nokogiri and Nokogumbo gems as part of the linkeddata gem to get everything in place. If you include gems individually, you can do so with no native dependencies.

The were "soft" dependencies, and they could be again, if there was enough demand by the community, but the documentation should be updated. They are soft dependencies from rdf-rdfa, rdf-microdata, and json-ld. It looks like the linkeddata gem is a development dependency for qa, so it could probably be deconstructed.

Since most people that want the complete linkeddata suite are like to want JSON-LD, Microdata or RDFa, it makes sense to have the native parsers as part of that. Otherwise, we'd need to have yet another gem which included them all.

But, I certainly like to hear feedback from the community.

[jrochkind]

What code is using Nokogumbo if available? I can't find it in this repo. Is it one of the gems "rolled up"? If so, should nokogumbo be a dependency (in the gemspec) of that gem specifically, rather than of linkeddata?

It wouldn't make any difference to me in the end, cause I depend on the qa gem, which depends on linkeddata, which depends on all it's "rolled up" gems -- so my app would get the "nokogumbo" gem anyway. But would probably be more and reliable to have the gem actually using nokogumbo express it as a dependency, rather than linkeddata that is not doing so?

I def understand the convenience of including everything you might want all together, the cost is my app now gets all these dependencies it's not actually using... but it's a trade off, and I think I'd make the same tradeoff, too hard to keep track of a bunch of microdependencies depending on exactly what functionality you are using.

Hmm, you're right that linkedata is expressed as just a development dependency of qa -- it seems to end up in my app dependency tree just the same as if it were a runtime dependency, I might have to read up on how development dependencies work exactly. qa has got a bunch, they all end up in my dependency tree.

[no-reply]

qa should probably not depend on linkeddata, which includes many gems that it won't use.

[gkellogg]

Fixedin 3.0.2.

[jrochkind]

@no-reply oh my gosh, I misdiagnosed, this stuff gets confusing.

Since qa only has a development_dependency on linkeddata, it's not that that is effecting my app, the developmetn dependencies practically have no effect on my app.

INSTEAD, it's that qa has a runtime_dependency on ldpath, and ldpath has a runtime dependency on linkeddata.

So the development dependencies are indeed irrelevant. And qa may be blameless -- if it's dependency on ldpath is correct.

Instead, the question is, does ldpath actually need a runtime dependency on the full linkeddata? Anyone familiar with that gem? I can go make an issue there.... it would be nice for my app that depends on qa not to have to pull in quite so much.

[no-reply]

Instead, the question is, does ldpath actually need a runtime dependency on the full linkeddata?

probably not. cc: @cbeer

[jrochkind]

Filed it as an issue on ldpath. Tried to explain it as best I could, this stuff gets confusing to talk about. https://github.com/samvera-labs/ldpath/issues/19