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.
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.