Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Please publish specs with the gems #68

drnic opened this Issue · 9 comments

3 participants


No description provided.


I'm sorry. I'm super blind. I saw only the line before. And that the vmc 0.3.23 gem doesn't have specs packaged in them.

@drnic drnic closed this

Why isn't the gemspec and other root files also being bundled? That is, why are there any files not being bundled into the gems?


Will you accept a patch to move to the gemspec that bundle gem NAME generates?

  spec.files         = `git ls-files`.split($/)
  spec.executables   = spec.files.grep(%r{^bin/}) { |f| File.basename(f) }
  spec.test_files    = spec.files.grep(%r{^(test|spec|features)/})
  spec.require_paths = ["lib"]

I'm intrigued, why would you want that stuff? We're moving to not package specs with the gem in general, because all it does it make the gem files bigger. These days it's easy enough to go find the gem source on github if you want to see how the sausage is made.


Just realised this repo is deprecated and its now cf repo.

Versioned gems are forever; repos change. For example, vmc => cf repo. I cannot easily find the specs & gemspec for the older vmc releases that work with CF v1. In part perhaps; and I'm not sure; but all the tags have been lost for the old gems.

Why does bundler's generated gemspec bundle every file if its not useful?

I don't think there are any large development-only assets in the vmc/cf gem? So just how big are we scared this gem will get?


Bundler's generated gemspec is probably a sane default because it can't know what you'll be doing with the structure of your project. I also don't like that loading the gemspec requires git to be installed, and that it makes assumptions about your working directory (has to be same as the .gemspec).

In general gems should only have what they need to be used - I certainly wouldn't want vmc and all of its dependencies to be grabbing code that's irrelevant to its functioning. For example, spec assets would be a concern, as we're starting to expand CF's integration specs and it's starting to include dummy rails/sinatra apps, etc.

We've started using a deployment script that automatically tags the repository when gems are cut, so you should be able to use those in the future. - v0.6.0 is when we cut over to cf and stopped caring about v1 APIs.


Also: VMC 0.3.x had no specs. So, there's that.

And CF does export some spec files, for example spec support libraries that its plugins can use to write their specs. But perhaps these should be extracted into a gem instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.