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

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.

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.

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

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?

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

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.

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.

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?

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

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

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