Indicate whether a gem will build extensions

[postmodern]

Indicate whether a gem has extensions set in it's gemspec. This will help users distinguish between native or FFI bindings from C/Java extensions. Additionally, malicious code could be executed via extensions at install time. Indicating the presence of such extensions would help the user be more suspicious of strange new gems.

[cmeiklejohn]

+1 to this idea... want to take a pass at implementing it?

[postmodern]

@cmeiklejohn I have no idea how this would be implemented, and am nearing the end of a contract.

[qrush]

I don't see why this is necessary. Bundler isn't going to show this info anyway. 👎 so far.

[postmodern]

@qrush a user should know before they install a Gem, if it will execute additional code during installation. Also, Bundler does indicate a gem is about to build extensions upon first installation:

Installing nokogiri (1.5.5) with native extensions .....
.........................................................................................................................................................................................................................................
Using bundler (1.2.1) 

However, I fail to see how this issue relates to Bundler at all.

Now that JRuby 1.7.0 no longer supports C extensions, it would be helpful to JRuby users to know if a library contains a C extension. Many C extensions are abandoned or fail to compile against their library. JRuby developers could query rubygems.org for the most popular abandoned/broken C extensions, and rewrite them using FFI. This would benefit all Ruby implementations.

[vassilevsky]

This is important. I would actually like to be able to tell if a gem builds an extension the sooner the better.

What if the gem page shows icons like #️⃣ (with tooltip) next to gem versions if they build extensions?
On gem list page, display the icon next to gem name if its most recent version builds an extension.

[Gedrovits]

+1 Very important for isolated systems without internet access, because we need to provide compiled way for them.

[arthurnn]

I am ok with this. Should not be that hard to build, if anyone interested in taking this task, go ahead.

[Gedrovits]

Will look into it.

[ghost]

+1 from me too. Perhaps it could also be shown on the gem-page on rubygems.org, something small, an indicator or a small icon. Most gems are pure ruby probably, the few that require extensions to be compiled, could perhaps have a big C or C++ letter or something somewhere on the right side or so. :)

[jc00ke]

Going a bit further, there could be a global gem setting that would force a prompt Y|n before a C-ext is compiled. By default the prompt should be off, but if set could show user a link or open C-ext dir in $EDITOR.

[simi]

Just to mention: rubygem extension != C compiled extension every time.

[vassilevsky]

What else could it be?

[simi]

When you provide

spec.extensions  = ["extconf.rb"]

in gemspec, when gem is running extensions compilation, it just run that script and expects also Makefile with install section. You can do whatever you want in extconf.rb if you provide fake empty Makefile for extension builder.

To mention some real usage: travis.rb was installing shell completion in this way before.

[simi]

I did a quick revisit of this feature request and it will need some effort to get implemented.

1. Add new column to store extensions metadata and in Pusher pull all info needed from spec.
2. Expose info in UI and API
3. Write a one time task to pull old specs and populate historical data as well.

Since this is an idea for now, I'm going to convert this into a discussion. PR or RFC is welcomed!