Gem Best Practices and or Template

[SandNerd]

The guide here is good but doesn't cover many other issues such as code organization (nicely written about here). Either way, and as beneficial guides can be, I think lack of a base/template gem and a metric tool might be a factor in explaining the extraordinary variability in quality seen when randomly looking at a gem source code.

Not sure why this topic isn't well covered since it's important to for an ecosystem to be built upon healthy components!

[indirect]

Thanks for reporting this! The base and template gem is provided by Bundler: bundle gem foo. There is an extensive guide to creating gems using Bundler (written by the wonderful @radar) located at http://bundler.io/v1.12/guides/creating_gem.html

[SandNerd]

IMHO this loose distribution of responsibility leads to getting little if anything done. This is aside from the confusion that novices face.

[nateberkopec]

IMHO this loose distribution of responsibility leads to getting little if anything done. This is aside from the confusion that novices face.

What do you mean?

Also, what did you mean by a "metric tool"?

[SandNerd]

Sorry for the ambiguity. To illustrate the confusion part, I copied this straight from Bundler homepage:

Bundler provides a consistent environment for Ruby projects by tracking and installing the exact gems and versions that are needed.

Bundler is an exit from dependency hell, and ensures that the gems you need are present in development, staging, and production. Starting work on a project is as simple as bundle install.

I must applaud whoever wrote this as it succiently describes what Bundler is and does. It's more or less the way I describe Bundler to anyone just starting their Ruby journey. Notice it said nothing related to 'gem building' and the like. After all, why would it? They're not called bundles, they're called gems.

In regards to responsibility distribution, a disclaimer: I do understand that this the open-source world and that team members usually overlap in related projects. Nevertheless, the way the projects are organized should be respected at least for the sake of if and when the team grows. And hey, why not just lower the bus factor.

By a metric tool I guess I meant a static code analyzer like rails_best_practices. It'd be awesome if it can have a quality score that can be turned into a badge one can put on their README page.

[nateberkopec]

Some people use Code Climate badges to show how "clean" the code is in their project, but clean code isn't, of course, the only thing a good Rubygem needs.

Some random thoughts:

• The bundle gem template is awesome, I use it all the time. Could Bundler provide a similar command for existing gems that looks for things like "Hey, you don't have a code of conduct. Would you like one? (y/n)" or "You haven't specified a license". etc. etc. bundle lint, you could call it.
• Something bundler could probably never do or require gem authors to do, but a lot of people think Rubygems should not emit warnings at runtime when Ruby is running in verbose mode. Could bundler somehow encourage gem authors to use Ruby verbose mode when developing/running their test suite?
• @mperham and I agree that most Rubygems shouldn't be incrementing the method or constant caches at runtime. Since that data is pretty easily available through RubyVM.stat, I wonder if we could make it more visible to gem authors.

[nateberkopec]

Er, none of those things I just mentioned are really related to the guides though, which is what this original issue is about. I think the guides as-is are pretty great.

As a start, maybe I could write something up about cache invalidation and ruby verbose mode to be added to the Practices section?

And maybe we could add a plug for some services a gem author should consider - like setting up a CI service, code metrics, etc.

[SandNerd]

The bundle gem template is awesome, I use it all the time. Could Bundler provide a similar command for existing gems that looks for things like "Hey, you don't have a code of conduct. Would you like one? (y/n)" or "You haven't specified a license". etc. etc. bundle lint, you could call it.

Again, I honestly don't understand why it wouldn't be gem lint. Out of curiosity, are there any technical, resources or even ideological reasons for why that's not acceptable?

[nateberkopec]

Now I see, you're frustrated that there's Rubygems and Bundler.

One of the goals of Ruby Together, which @indirect is paid by, is unifying Rubygems and Bundler. It's a very big project technically, both projects are very old and have a lot of features and history. TBH I don't know why bundle gem lives in bundler and not rubygems, but I guess I wouldn't worry about it too much because eventually these projects will be merged (sign up for rubytogether and make it happen faster! ;)

[SandNerd]

Tear down this wall!

Great to hear that there's such a unification effort already going on. Any time frame for when that is to happen? Will there be a separate Github project for that effort? I'm asking as I truly dislike suggesting things (like this issue here) for it to become yet more work in the way of higher importance projects such as this unification.

[segiddins]

rubygems/rubygems#1681

[bf4]

@sahal2080 fwiw, I once make a thor-based Gem generator that vendored and extended bundler's template, similar to how Rails templates work: https://github.com/bf4/gemnerator/tree/master/bundler_template It might be a nice basis for allowing extension/modification of a bundler gem template with a -T option like Rails has ¯\_(ツ)_/¯