Toplevel .gemspec

[jeremy]

Provide a toplevel gemspec (extracted from Rakefile) for Bundler friendliness.

[stevecheckoway]

I'm not sure I have an opinion on this, but I'm curious what the motivation is. Nokogiri, for example, is quite explicit that they don't want one.

[jeremy]

For Bundler compatibility (e.g. see gjtorikian/html-proofer#362 (comment)). I get the author's reasoning, but in practice the few people who do need this just end up frustrated. You can't test against bleeding edge and make your own risk management decision because the upstream author has ruled it out, often for great and well-meaning reasons, like getting too many support-request issues.

https://bundler.io/man/gemfile.5.html

A git repository SHOULD have at least one file, at the root of the directory containing the gem, with the extension .gemspec. This file MUST contain a valid gem specification, as expected by the gem build command.

If a git repository does not have a .gemspec, bundler will attempt to create one, but it will not contain any dependencies, executables, or C extension compilation instructions. As a result, it may fail to properly integrate into your application.

[stevecheckoway]

Note that the bundler page is talking about what should be there if you are using a git repo as a source, "If necessary, you can specify that a gem is located at a particular git repository using the :git parameter" (emphasis mine).

It's probably not a great idea to depend on whatever happens to be current in master, though. For example, I realized that (in a pretty unlikely circumstance), the current master can leak the entire Gumbo parse tree.

[jeremy]

Yep, for sure. I'm not adding anything new to this topic, as it's been very thoroughly debated/bikeshedded over the years 😅. I personally fall on the provide sharp knives side of the "risk management" question: yes it's almost always a bad idea; sometimes it isn't, and then it feels silly.

The only new contribution here is specific context: one library dev branch tracking another library dev branch. In order to test a work-in-progress branch of html-proofer against latest nokogumbo, we must either include nokogumbo as a submodule or fork it to provide a gemspec so we can depend on it.

(This is a common approach for "canary" CI testing, too: build your library/app against the latest dev branches of your dependencies instead of their stable releases, giving an early warning about incompatibility/bugs/breakage. Risk management!)

[stevecheckoway]

Gotcha, thanks for explaining your thinking.

[stevecheckoway]

By the way, the travis failure is unrelated to this PR. I don't know for sure what's going on, but I deleted the bundler cache and started those builds again.

[flavorjones]

In case it's relevant, I'll mention that Nokogiri provides the ability to generate (in a local clone of the repo) a .gemspec file to accommodate anyone who wants a sharp knife, by running rake gem:spec. This is what nokogiri-core chose to do to support bleeding-edge use cases while avoiding bleeding-edge support requests ... YMMV of course.

[rubys]

On the topic of gemspecs, I totally defer to @jeremy. What exists in nokogumbo was probably something I copied from someplace years ago and served my purposes at the time. @jeremy knows this stuff.

[stevecheckoway]

Sounds good to me!

[jeremy]

Cheers @stevecheckoway 😊