minor: remove spec files from gem

[e2]

There little benefit in having 'spec' files installed with RuboCop every time.

[bbatsov]

Most gems seem to ship their specs and that why we do so as well. I don't have a strong preference either way.

[e2]

TL;DR - shipping specs is the wrong thing to do, no matter how you look at it. Lots of people are doing it wrong, unfortunately.

I've spent hours trying to figure out what "development" means for Ruby gems... and I finally "got it".

(I should write a blog about it ... haven't go to it yet).

In a nutshell, add_development_dependency is obsolete - nowadays it serves no purpose except as useless metadata on rubygems.org (long story). It especially doesn't make sense since RuboCop has bundler as a development dependency anyway.

And if you have 'bundler' as a development dependency, it makes sense to put all the dev deps in the 'Gemfile'.

So, the 'pendantic' thing to do would be: move dev deps (except 'bundler') from the gemspec to the Gemfile (into a :development group). This makes the gemspec a pure "runtime"/"release" thing used only for BUILDING (!) gems.

Next, since contributing to RuboCop requires a pull request, you need the source anyway (unless you expect people to somehow ... craft ... PRs ... from ... a ... diff ??).

And, even if tests fail for a released gem, the response is almost always "do they work on master?".

Most gems seem to ship their specs

That's because people are trying to do the right thing by copying other people instead of understanding what's going on (which is actually pretty tough given all the legacy stuff involved here).

The result is lots of wasted bandwidth, disk space (in terms of allocated space), access times (find/grep take ages), wasted developer time (trying to work out the right setup for Travis using --without=development) ... just because once upon a time (in a galaxy far, far away) ... in a pre-bundler/pre-github world ... people used to run gem install --dev.

(While their ancestors used to install gems using setup.rb.)

[bbatsov]

Good arguments! I'm ok with updating the gemspec provided @jonas054 and @yujinakayama agree as well.

[jonas054]

I agree too, based on the arguments presented by @e2, which seem thoroughly thought through. My own knowledge of specifying dependencies or shipping gems is limited, I find.

[swatosh]

One argument for including the specs (maybe not relevant to rubocop) is to provide actual working examples of usage.

[e2]

TL;DR - even including docs in gems used to be a good idea, but now it's more of a problem

@swatosh - that should be in the README or in a examples subdir.

Specs are actually better for documenting behavior (e.g. doc formatting in RSpec) or testing edge cases - so they rarely make good usage guidelines. (Especially with isolated testing).

Acceptance tests are better - to the point that they are much prettier online (e.g. for relisapp.com). Regardless, reading updated documentation online is better anyway - especially since good docs coverage is often really heavy.

For documentation and examples, ri and rdoc should be better suited - and even then people put gem: --no-ri --no-rdoc in their ~/.gemrc to prevent them being generated locally. (For offline docs, gem server was the solution).

Not to mention: navigating to a installed gem location is troublesome.

I now think of gems as a 'versioned snapshot of code intended for apps, not humans'.

RubyGems wanted to be "more" a long time ago (doc, tests, dependencies, rubyforge), but that didn't work out well in the end.

If a gem's specs have to be read to get a working example - then that project seriously needs a PR for the Readme ;)

[bbatsov]

@e2 You have our blessing to do the changes you suggested. :-)

[mvz]

As a counter-argument, Debian uses the tests/specs from the gem to run the tests when creating a .deb package.

As an aside, @e2, why do you conclude that add_development_dependency is obsolete? I recently read a discussion on a GitHub ticket for RubyGems (I can probably find it again), where the conclusion was that it specifies the gems needed for building the gem (e.g., rake-compiler).

[e2]

@bbatsov - I also removed the *.eps files. Makes the gem less "huge".

[e2]

TL;DR - why unit tests don't make sense when packaging debs + why dev deps are obsolete

@mvz - I can discuss the issue in depth, so feel free to ask me to explain myself more

Tests/specs basically don't make sense from a maintainer's point of view because:

1. they are mostly unit tests, so they don't test dependencies with other packages or arch-specific stuff (we're talking about Ruby here)
2. a maintainer needs (only) feature/acceptance or system integration tests - if those are not provided by the gem author, it's up to the gem author to deal with those issue (adding unit tests / acceptance tests)
3. a maintainer's job is only to make sure the package is installed correctly with the right dependencies - unless they are building from a repository which has no official releases (which is not the case here)

So in this case, it makes no sense to run a gem's unit tests from a released gem. For a CI - it's better to clone the repo by tag anyway (since additional dev tools or steps may be needed for testing anyway).

"released" means "ready for use", which implies all the tests pass on every environment. Otherwise, you'd be using rubocop tests to test the environment, not the gem itself. (Instead it would make more sense to run the rubygems and bundler gem tests - which would be more thorough).

As for add_development_dependency, basically the meaning of "development" has changed over the years. It depends on the individual whether e.g. "testing" is part of "development" or not. Is packaging considered development? Usually, very few people can release a gem - so building only really makes sense for those 2-3 people (compared to the millions of downloads).

Historically, add_development_dependency is a pre-bundler thing, where you installed gems using gem install --dev. What it really should be called is: add_build_dependency - but that's not going to change any time soon. Again - is "building" considered "development"? If so, then PRs cannot be considered "development".

The point is - development workflows changed much faster than Rubygems can deal with (because it has to be backward-compatible with even the most ancient gems out there) - which is why add_development_dependency will likely never be deprecated.

And with bundler as a dev dependency anyway, it just makes more sense to put things like rake-compiler in the Gemfile.

As an analogy - you don't get a full development kit and manufacturing tests when you buy a smartphone. You get just the smartphone. Even if you're a re-seller.

As a side note, test_files was meant for gem install --test, which is no longer a valid option. That's because at first there was just Ruby's unit/test - then came all the various test frameworks (which made the option useless and it's why it was removed).

My point - learning by "copying others" doesn't work well where there's too much legacy baggage to deal with.

P.S. gem list rake-compiler shows nothing on my system - even though I have currently over 261 gems installed. Probably because I'm not an owner of a gem that needs compiling extensions - and if I was, I'd be the one creating the official gem in the first place - so why would I put gem build tool deps inside a gem that only I can really build? (the exception here are gems which cannot be built by Bundler from source, like zeus - because it needs golang build tools).

P.S.2 - I know people "hack" on code in installed gems to debug issues. A better approach is to immediately use Bundler with path sources and a checked out master branch - because the hacking/debugging is more likely to result in a good PR.

[mvz]

@e2 your comment was indeed TL, so I DR it until now ;-).

Most of your arguments are based on an ideal world where gem authors test their gems on all platforms and versions of Ruby (1.9.3 on little-endian ARM, perhaps?), and where there is a perfect separation of unit and feature/integration tests. This world, however, does not exist.

In reality, tests are a very useful tool to find out hidden bugs and dependencies before they hit the end-user of a package. If Debian were to make CRuby 2.2 their default Ruby implementation, how else are they going to find out if the existing packages at their existing versions will still work?

[bbatsov]

Btw, bundler no longer includes a tests stub for new gems, so I guess there consensus that the tests don't belong there. People repackaging gems can always make use of the original test suite IMO.

[andremedeiros]

Actually, if I may drop my $0.02 here:

@bbatsov: Bundler will generate a tests stub, if you so choose it. We don't force it onto you, the same way we don't force a license or the code of conduct anymore. You choose how you want it.

As for the whole To Include or not To Include [specs] argument, I'm in favour of including them. There's a lot to be learned from a gem's specs (even if you don't run them), and as an avid user of bundle open, I tend to read a lot of them. Sorry, let me rephrase that. I tend to read a LOT of them.

As for moving away from add_development_dependency, I mostly agree with you that it should be within a development group in the Gemfile. As it stands tho, that only works with Rails because groups are loaded depending on what environment you're on (which is why :development and :test work right out of the box), and so, it has to be explicitly loaded. The way we do that separation now consists on the scenario you're working from:

• Installing gems as a dependency of something else: in this case, bundler will hit the dependency API, and the gems that are necessary to run the app are the ones considered a dependency (i.e. runtime, not development.) Have a look here to see what I'm talking about.
• Installing gems locally: if you happen to run bundle on a locally checked out version of a gem, it will then install all dependencies (runtime and development.)

I hope this makes you reconsider your stance on shipping the specs.