Sourcing haml from git hub is broken cause its gemspec needs access more files #44

Closed
SamSaffron opened this Issue Feb 7, 2010 · 12 comments

Projects

None yet

6 participants

@SamSaffron
Contributor

When you source haml from github it fails due to:

http://github.com/nex3/haml/blob/master/haml.gemspec

having this line:

spec.version = File.read('VERSION').strip

fixing this is a bit of a cluster ...

@jeremy
Contributor
jeremy commented Feb 7, 2010

This is a HAML bug, and a bad one. Fix upstream.

@SamSaffron
Contributor

I reported this now: http://github.com/nex3/haml/issues/issue/85

I suggest a death match :) are any other gemspecs out there doing the same trickery. You could theoretically work around this by cloning in a non-bare fashion.

@nex3
Contributor
nex3 commented Feb 7, 2010

I don't consider this a bug. The VERSION file is where Haml stores its version number; all uses of the version number read from there. This keeps it nice and DRY.

@chriseppstein

Why isn't the Haml gemspec generated then? Jeweler makes this pretty easy.

@nex3
Contributor
nex3 commented Feb 7, 2010

Because I don't want to leave an out-of-date gemspec lying around the repository, nor do I want to remember to update it every time I add a new file.

Why can't bundler use the static gemspec generated by RubyGems?

@carllerche
Contributor

We do, unless haml from git is requested. In that case, we don't have the static gemspec and can't support haml.

@nex3
Contributor
nex3 commented Feb 7, 2010

What do you do about projects that don't check in the gemspec, such as many of those that use Jeweler? Are they also unsupported?

It seems to me that the best solution here is to do a non-bare checkout of the repository. A development version of a repository is in flux, and the lack of a consistent static gemspec reflects that.

@jeremy
Contributor
jeremy commented Feb 7, 2010

The only issue with this .gemspec is its brittle expectation of how it'll be loaded. Just doing File.expand_path('../VERSION', FILE) would resolve it.

Repositories without a .gemspec have one fashioned for them. Recommend that those using Jeweler also check in the generated .gemspec for convenience. However, it would be nice to have a conventional way to generate a gemspec if it doesn't exist, such as trying rake gemspec before proceeding.

@nex3
Contributor
nex3 commented Feb 7, 2010

Oh, well, if that's the only issue then I'll be happy to fix it. Would this also require properly scoping the FileList calls?

@nex3
Contributor
nex3 commented Feb 13, 2010

I can't really fix this properly until I know whether or not the FileList stuff has to be updated as well...

@indirect
Member

Is there any reason not to scope properly scope the FileList stuff?

@nex3
Contributor
nex3 commented Feb 14, 2010

It's more code noise. It's possible that FileList automatically scopes properly, in which case it would also be redundant.

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