"gem build" eval's gemspec without passing filename.

Stephen Touset's Avatar

Stephen Touset

17 Feb, 2010 06:24 PM

It's minor, but when "gem build" eval's a gemspec, it really ought to pass the filename as a parameter. This allows constants like FILE to be accessed inside the gemspec.

A common use-case for this functionality is having a version number in an external file, with "spec.version = File.read('VERSION')". This is completely impossible given the current implementation, because if the gemspec is executed with the pwd outside of the gem's root directory, there's no way to establish what the root directory is.

  1. Support Staff 1 Posted by Eric Hodel on 17 Feb, 2010 10:07 PM

    Eric Hodel's Avatar

    The gemspec is meant to be a data file. You should use a tool like hoe to manage this for you.

  2. Eric Hodel closed this discussion on 17 Feb, 2010 10:07 PM.

  3. Stephen Touset re-opened this discussion on 17 Feb, 2010 10:21 PM

  4. 2 Posted by Stephen Touset on 17 Feb, 2010 10:21 PM

    Stephen Touset's Avatar

    Another issue behind this is that exceptions raised in the gemspec have useless debugging output that appears to come from (eval). raggi in #rubygems posted http://pastie.textmate.org/private/omtbdlsceegmwvja5qt5dq as an example.

    There was a discussion on this in #rubygems, and the use-case behind this scenario is that I am trying to use a tool to manage this, namely the version gem (http://github.com/stouset/version). It's extracted logic from the Jeweler gem that handles version-numbering, but it doesn't generate the whole gemspec for you. Thus, you would read in the version number from a VERSION file in the project's directory.

    It should be a simple matter of changing an eval(spec) to eval(spec, binding, filename), and I'm planning on submitting a patch later this evening which does exactly that. I don't think Rubygems should inherently restrict you to specific workflows or toolchains on this kind of matter, so I'd appreciate you reconsidering the decision to close the issue.

  5. 3 Posted by John Barnette on 17 Feb, 2010 10:30 PM

    John Barnette's Avatar

    It's best not to think of .gemspecs as code. They look like code, they're even evaled to load 'em, but you should really think of them as opaque data files. They're Ruby because depending on Ruby's parser to load the data is better than depending on Marshal or YAML (both options have serious cross-implementation and bootstrapping problems). The fact that the file happens to be executable Ruby is an implementation detail.

    The overall bropinion is this: Your build framework (be it Hoe, Jeweler, or a homebrew Rakefile) is responsible for writing out a fully resolved gemspec -- a spec that's purely data, and could just as easily be expressed as, say, YAML.

    Your gemspec should be rewritten if, say, you have a "version:bump" task that updates an external VERSION file.

  6. 4 Posted by Stephen Touset on 17 Feb, 2010 10:33 PM

    Stephen Touset's Avatar

    I didn't think about the direction of generating a gemspec from the rake task, but that does sort of invert the dependency logic (version:bump should post-depend on the gemspec regeneration task).

    I can go that route. But at the end of the day it still might be a good idea to pass the filename as an argument, if only for better error reporting.

  7. 5 Posted by John Barnette on 17 Feb, 2010 10:50 PM

    John Barnette's Avatar

    I don't see anything wrong with, say, eval(spec, nil, file) for better exceptions, but I'd definitely like to avoid passing a binding: A gemspec that depends on a binding is no longer just data.

  8. 6 Posted by Stephen Touset on 17 Feb, 2010 10:54 PM

    Stephen Touset's Avatar

    I can agree with that. Is it currently passing nil? If it's passing nothing, I believe it defaults to the current binding.

  9. 7 Posted by James Tucker on 08 Mar, 2010 07:38 PM

    James Tucker's Avatar

    I've passed the filename through in r2461, not passing a binding.

  10. 8 Posted by Stephen Touset on 08 Mar, 2010 07:39 PM

    Stephen Touset's Avatar

    That works. Thanks!

  11. James Tucker closed this discussion on 08 Mar, 2010 07:59 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac