Please publish specs with the gems #68

Closed
drnic opened this Issue Mar 30, 2013 · 9 comments

Projects

None yet

3 participants

@drnic
Contributor
drnic commented Mar 30, 2013

No description provided.

@drnic
Contributor
drnic commented Mar 30, 2013

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 Mar 30, 2013
@drnic
Contributor
drnic commented Mar 30, 2013

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?

@drnic
Contributor
drnic commented Mar 30, 2013

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"]
@mkocher
mkocher commented Mar 30, 2013

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.

@drnic
Contributor
drnic commented Mar 30, 2013

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?

@vito
Contributor
vito commented Mar 30, 2013

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.

https://github.com/cloudfoundry/cf/tags - v0.6.0 is when we cut over to cf and stopped caring about v1 APIs.

@vito
Contributor
vito commented Mar 30, 2013

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.

@drnic
Contributor
drnic commented Mar 30, 2013

Ok, thanks guys.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment