search

rubygems / bundler

Manage your Ruby application's gem dependencies
https://bundler.io
MIT License
4.88k stars 2k forks source link

Use `rspec --init` to generate skeleton files for gems using rspec #3035

Closed myronmarston closed 7 years ago

myronmarston commented 10 years ago

I just learned about the -t option to bundle gem. rspec --init similarly generates the skeleton files for using RSpec on a project. Would you be open to using rspec --init instead of your own templates? The files generated by rspec --init include more settings for a good out-of-the-box experience:

https://github.com/rspec/rspec-core/blob/a944fbfe7cd2ff6557d962b85f98c2494919a640/lib/rspec/core/project_initializer/dot_rspec

https://github.com/rspec/rspec-core/blob/a944fbfe7cd2ff6557d962b85f98c2494919a640/lib/rspec/core/project_initializer/spec_helper.rb

indirect commented 10 years ago

Good idea. We can pull in the files that rspec generates, or tell people to run rspec --init. (I don't want to have bundler depend on the rspec gem itself.)

On Wed, May 14, 2014 at 6:18 AM, Myron Marston notifications@github.com wrote:

I just learned about the -t option to bundle gem. rspec --init similarly generates the skeleton files for using RSpec on a project. Would you be open to using rspec --init instead of your own templates? The files generated by rspec --init include more settings for a good out-of-the-box experience: https://github.com/rspec/rspec-core/blob/a944fbfe7cd2ff6557d962b85f98c2494919a640/lib/rspec/core/project_initializer/dot_rspec

https://github.com/rspec/rspec-core/blob/a944fbfe7cd2ff6557d962b85f98c2494919a640/lib/rspec/core/project_initializer/spec_helper.rb

Reply to this email directly or view it on GitHub: https://github.com/bundler/bundler/issues/3035

simi commented 10 years ago

I don't think it is big problem to run rspec --init after bundle gem. I'm doing it without problem. You're getting latest files. Also this will be good candidate for Bundler plugin system. And finally this is not an issue according to https://github.com/bundler/bundler/blob/master/ISSUES.md.

indirect commented 10 years ago

I'm accepting it as a bug report ("you don't generate a current rspec skeleton") from the author of rspec. Bundler can try to run rspec --init, I guess, but I don't want to have to deal with machines that don't have rspec installed yet.

Myron, does the skeleton change a lot? Can we just ship it with bundler for now?

On Wed, May 14, 2014 at 3:45 PM, Josef Šimánek notifications@github.com wrote:

I don't think it is big problem to run rspec --init after bundle gem. I'm doing it without problem. You're getting latest files. Also this will be good candidate for Bundler plugin system. And finally this is not an issue according to https://github.com/bundler/bundler/blob/master/ISSUES.md.

Reply to this email directly or view it on GitHub: https://github.com/bundler/bundler/issues/3035#issuecomment-43089602

simi commented 10 years ago

but I don't want to have to deal with machines that don't have rspec installed yet

@indirect isn't it as is as if defined?(RSpec) in bundle gem procedure?

andremedeiros commented 10 years ago

You'd probably have to require rspec for that, and rescue from a LoadError.

myronmarston commented 10 years ago

Originally, I was thinking that since we are generating the gem skeleton with rspec, it would already be installed, and rspec --init would be safe to run, but you're right; we can't assume that.

Myron, does the skeleton change a lot? Can we just ship it with bundler for now?

It hasn't changed much historically. It's quite different now then it used to be, though.

My suggestion is to have copied of the files in bundler, and a spec here in bundler that checks its files against the ones RSpec generates -- that way, if/when we do update our generated files, and bundler upgrades its spec suite to that RSpec version, you'll have a failing test telling you to they are out of sync.

simi commented 10 years ago

@myronmarston I think it is not good idea to keep some file synced across bundler and rspec.

myronmarston commented 10 years ago

@myronmarston I think it is not good idea to keep some file synced across bundler and rspec.

It's not ideal, but I think it's the best of the options proposed so far. One other idea: if bundle gem were to run bundle install after generating the gem skeleton it could then run bundle exec rspec --init and know that rspec's installed. There would be no file syncing needed then. That has downsides, though...it would make bundle gem take longer and be dependent on an internet connection.

indirect commented 10 years ago

Bundler is basically the king of not-ideal code copying. :) It's not great, but it sounds like the least bad option to me, too.

On Wed, May 14, 2014 at 5:52 PM, Myron Marston notifications@github.com wrote:

@myronmarston I think it is not good idea to keep some file synced across bundler and rspec.

It's not ideal, but I think it's the best of the options proposed so far. One other idea: if bundle gem were to run bundle install after generating the gem skeleton it could then run bundle exec rspec --init and know that rspec's installed. There would be no file syncing needed then. That has downsides, though...it would make bundle gem take longer and be dependent on an internet connection.

Reply to this email directly or view it on GitHub: https://github.com/bundler/bundler/issues/3035#issuecomment-43106799

simi commented 10 years ago

What about to add some simple minimal spec_helper?

Just:

require 'bundler/setup'
require 'gem_name'

RSpec.configure do |config|
end

I think this works for years now.

myronmarston commented 10 years ago

What about to add some simple minimal spec_helper?

That's very similar to what bundler generates now. rspec's generated files are much more full featured, though:

https://github.com/rspec/rspec-core/blob/a944fbfe7cd2ff6557d962b85f98c2494919a640/lib/rspec/core/project_initializer/spec_helper.rb

While it's not necessary for users to get that generated file, we (the RSpec team) have put a lot of thought into the generated files and I think users would benefit from getting them when initializing a gem via bundle gem.

simi commented 10 years ago

Yup, I just removed all those comments, since they can change from version to version. So I'm :-1: about adding this and sync it instead of manual rspec --init after bundle gem. But you know, @indirect is boss here. So let him decide.

mikegee commented 10 years ago

One other idea: if bundle gem were to run bundle install after generating the gem skeleton it could then run bundle exec rspec --init and know that rspec's installed. There would be no file syncing needed then. That has downsides, though...it would make bundle gem take longer and be dependent on an internet connection.

I like the idea this full-featured new gem experience. It's a lot like rails new. I don't like that Bundler is responsible for it. Has there been discussion around extracting bundle gem?

indirect commented 10 years ago

No, and yes, respectively.

On Sun, May 18, 2014 at 8:48 PM, Michael Gee notifications@github.com wrote:

One other idea: if bundle gem were to run bundle install after generating the gem skeleton it could then run bundle exec rspec --init and know that rspec's installed. There would be no file syncing needed then. That has downsides, though...it would make bundle gem take longer and be dependent on an internet connection.

I like the idea this full-featured new gem experience. It's a lot like rails new. I don't like that Bundler is responsible for it. Has there been discussion around extracting bundle gem?

Reply to this email directly or view it on GitHub: https://github.com/bundler/bundler/issues/3035#issuecomment-43449523

e2 commented 9 years ago

I found this issue as I wanted to propose moving to RSpec '~> 3.0' (in the gemspec/Gemfile).

There's no reason to allow RSpec 2.x, since 2.99 is compatible with all other 2.x versions, migration from 2.99 to 3.x is smooth/trivial (AFAIK - thanks to the transpec gem).

So I'd propose using RSpec 3.x-only compatible templates.

This would side-step the "rspec --init" problem (until RSpec grows more features), especially since current cool features can be uncommented by default (since it's a new gem), like:

and extras such as:

I see absolutely no upside from supporting RSpec 2.x, while I can't think of any way how enabling the above features would hinder development on new gems.

Also, I'm not in favor of rspec --init because there may be important differences (like taking Travis into account).

I'd gladly prepare a PR for this - as long as there are no objections to locking to 'rspec ~> 3.0'. (Or 3.1 for that matter).

coilysiren commented 8 years ago

@e2 likely had other code to write, so anyone can work on a PR for this

(assuming the feature wasn't added in already)

segiddins commented 8 years ago

Looks like we already use rspec 3...

e2 commented 8 years ago

FWIW, the template locks to RSpec 3.x since: https://github.com/bundler/bundler/commit/1691f6ab287d047913b9cee3c25e7e2493311034

The spec_helper file generated by rspec --init hasn't changed since v3.0.3.

Personally, I use most of the commented out options there. The benefit is having a decent default "cheetsheet" of options. I actually would prefer the options to be less "documented" there and more of them commented out by default.

I see 2 "reasonable" options:

  1. Include a url to a decent "RSpec starter template" inside the minimalistic spec_helper.rb created by bundle gem
  2. Show a warning from within the spec_helper.rb that RSpec isn't configured. This deserves a warning because newbie users are going to be missing out on useful features. E.g. the warning can tell the user to run rm -f spec/spec_helper.rb && bundle install && rspec --init.

I'd prefer option 1, because it allows enabling more features by default. (rspec --init understandably has to be conservative with what it turns on).

On the flip side, I doubt a new gem will even have lots of tests to being with, so a "full-blow development environment" probably doesn't suit what bundle gem is supposed to help with. (Which is: just create something basic enough to push to RubyGems or a private gem server).

myronmarston commented 8 years ago

The spec_helper file generated by rspec --init hasn't changed since v3.0.3.

It's changed several times since 3.0.3:

indirect commented 8 years ago

oh man, yes, we should get example_status_persistence_file_path into the default gem template, that makes things so much better. 👍 for adding tooling and a spec so that we ship the up-to-date spec helper.

e2 commented 8 years ago

It's changed several times since 3.0.3:

I only checked the diff between earliest and latest, to show that if Bundler included the template hard-coded from 3.0.3, it wouldn't need updating as of today to just work - and it would still be better than the default because of the documented options available for users to activate.

I'd set the constraint to '~> 3.4', because it's a waste of time to wonder if a given template will work on an earlier RSpec in this case.

The RSpec team already puts a ton of effort into making sure things work smoothly, so unless I'm missing something, installing RSpec 3.[0-3] instead of 3.4 makes no sense. Also, this way features and be enabled explicitly with default values - instead of commenting them out in a =begin =end section.

segiddins commented 7 years ago

I'm going to close this for now, but people can feel free to make PRs improving the skeleton files we generate, thanks for the lively discussion!