seattlerb/ruby_parser

Gemspec?

Closed this issue · 5 comments

Just curious: is there any reason this gem is missing a .gemspec in its git repo (but, obviously, has one on rubygems.org)?

I see #119, which is from 8 years ago, but not sure what the reasoning is was then, or if it still applies, so I thought I'd ask.

My use case is we use brakeman (which depends on this gem), and I attempted to use beginless/endless ranges in my project, which are supported in master (as of 2d19d4e) but not in the release.

Barring that, is there any way you could be convinced to push a release (a beta would be just as good)?

Basically, the parser is built when the gem is built. So just pointing at the source code in git won't work. If you have your own place to host gems, you could build the gem (rake gem) and push it there.

Otherwise, I released the brakeman gem version 5.0.1 with the latest RubyParser changes bundled.

@presidentbeef thanks for the release!

I'm not sure I understand though. When you say "the gem" do you mean ruby_parser? If so, how does that matter? Lots of gems do that. Pointing your Gemfile at this repo would then just make it build on bundle update.

Yes, that is what I meant.

I've never had to deal with a gem that builds/compiles anything on install, but I see that it is possible.

I might take a stab at making this work - a lot of how RubyParser is built are buried in Hoe and the Rakefile.

Oh wow. Yeah, anything that uses native C extensions (or system libraries) involves that. nokogiri and ruby-concurrent-ext are the first that come to mind, but definitely more complex examples. I found this one which is a good, basic example (though you clearly know what you're doing, so maybe that's unnecessary 😄. But yeah, that change would definite make it fit more cleanly into the ruby gem structure.

If you want to also distribute the compiled binaries when you push to rubygems, that's sometimes done too as a fallback for those without a compiler. Being able to compile your own easily through the bundler pipeline also makes people feel better about security as well.

Anyways, thanks for the openness to look into it.

Part of the problem is that the racc runtime ships with ruby and has a gemspec registered... but the racc compiler has the same name... so the dependency is met... it's all a bit screwy. Still... ruby_parser ships as a "compiled" gem in order to avoid problems with the racc dependency.

And I don't commit a gemspec for the same reason I don't commit the compiled parser code... they're generated code. Hoe takes care of all my gemspecs + deployment + everything else for all my projects.