New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Comments

Projects
None yet
6 participants
@SamSaffron
Contributor

SamSaffron commented Feb 7, 2010

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

This comment has been minimized.

Show comment
Hide comment
@jeremy

jeremy Feb 7, 2010

Contributor

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

Contributor

jeremy commented Feb 7, 2010

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

@SamSaffron

This comment has been minimized.

Show comment
Hide comment
@SamSaffron

SamSaffron Feb 7, 2010

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.

Contributor

SamSaffron commented Feb 7, 2010

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

This comment has been minimized.

Show comment
Hide comment
@nex3

nex3 Feb 7, 2010

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@chriseppstein

chriseppstein Feb 7, 2010

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

chriseppstein commented Feb 7, 2010

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

@nex3

This comment has been minimized.

Show comment
Hide comment
@nex3

nex3 Feb 7, 2010

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@carllerche

carllerche Feb 7, 2010

Contributor

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

Contributor

carllerche commented Feb 7, 2010

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

@nex3

This comment has been minimized.

Show comment
Hide comment
@nex3

nex3 Feb 7, 2010

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@jeremy

jeremy Feb 7, 2010

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@nex3

nex3 Feb 7, 2010

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@nex3

nex3 Feb 13, 2010

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Feb 14, 2010

Member

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

Member

indirect commented Feb 14, 2010

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

@nex3

This comment has been minimized.

Show comment
Hide comment
@nex3

nex3 Feb 14, 2010

Contributor

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

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