rack's head contains important bug fixes, but the gem is unbuildable, then unusable
Sam Roberts
http://github.com/sam-github/rack/tree/gem-buildable
Two problems with it.
One is that it requires the unit tests to run and pass. This is
unfortunate, because they don't on my machine, even after installing a
raft-load of development dependencies. The maintainers should make
sure the tests pass before releasing :-), the rest of should be able
to build gems without running the test suite. I'd supply a patch for
this, but nothing in the Rakefile seems to specify the dependency, so
I hacked the tests out instead.
The other is that when built from a git checkout, the gem uses a
internal git number for the version of the gem. This happens to be
0.3.283 on my repo, whereas the latest release is 0.9.1. Since gems
have the marvelous property of enforcing version dependencies, sinatra
refuses to use it:
RubyGem version error: rack(0.3.283 not >= 0.9.1, < 1.0) (Gem::LoadError)
rack/rack/master either needs to be tagged so that git describe
returns a meaningful version, or the Rakefile algorithm needs
improvement. My patch does the latter, and updates Rack.release to
"0.9".
Could this be fixed?
Cheers,
Sam
Christian Neukirchen
> One is that it requires the unit tests to run and pass. This is
> unfortunate, because they don't on my machine, even after installing a
> raft-load of development dependencies. The maintainers should make
> sure the tests pass before releasing :-), the rest of should be able
> to build gems without running the test suite. I'd supply a patch for
> this, but nothing in the Rakefile seems to specify the dependency, so
> I hacked the tests out instead.
>
> The other is that when built from a git checkout, the gem uses a
> internal git number for the version of the gem. This happens to be
> 0.3.283 on my repo, whereas the latest release is 0.9.1. Since gems
> have the marvelous property of enforcing version dependencies, sinatra
> refuses to use it:
I'll revamp the build and release scripts before 1.0.
But it's such an unpleasant task. ;)
--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org
Christian Neukirchen
> One is that it requires the unit tests to run and pass. This is
> unfortunate, because they don't on my machine, even after installing a
> raft-load of development dependencies. The maintainers should make
> sure the tests pass before releasing :-), the rest of should be able
> to build gems without running the test suite. I'd supply a patch for
> this, but nothing in the Rakefile seems to specify the dependency, so
> I hacked the tests out instead.
>
> The other is that when built from a git checkout, the gem uses a
> internal git number for the version of the gem. This happens to be
> 0.3.283 on my repo, whereas the latest release is 0.9.1. Since gems
> have the marvelous property of enforcing version dependencies, sinatra
> refuses to use it:
>
> RubyGem version error: rack(0.3.283 not >= 0.9.1, < 1.0) (Gem::LoadError)
>
> rack/rack/master either needs to be tagged so that git describe
> returns a meaningful version, or the Rakefile algorithm needs
> improvement. My patch does the latter, and updates Rack.release to
> "0.9".
Ok, first stab at a new build system:
http://github.com/chneukirchen/rack/tree/build
Esp. see:
http://github.com/chneukirchen/rack/blob/97dc302cf1290a8c54c77ccc2a50c4b23fccc45a/do/README
Most of these scripts really should be shell scripts, but Windows
users should be able to build gems as well. Maybe we can write the
anyway Unix specific tasks as shell scripts, though.
The new scripts don't run tests unless you do an official build.
The user scripts have as few dependencies as possible.
Package builds now need explicit version numbering, because I can't
come up with a proper heuristic. If anyone has a good idea, please
speak up.
Other comments are welcome as well.
Christian Neukirchen
> Most of these scripts really should be shell scripts, but Windows
> users should be able to build gems as well.
Ah, one more thing. We'll have a gemspec in the repository and
releases in near future, so Github can build gems as well. See
do/mkgemspec.
I'm tired of fighting the system.
Ryan Tomayko
Interesting approach. What made you go with separate scripts instead
of Rake tasks? Just the amount of code required?
I was able to build a gem and tarball without too much trouble at all.
Not having dependencies (e.g., having SPEC and ChangeLog built when
do/package is invoked) might lead to some confusion because you need
to execute things in a certain order but other than that everything
looked good.
Consider me +1 - not being able to build gems easily from the source
tree is a pretty big issue right now.
Thanks,
Ryan
Christian Neukirchen
> Interesting approach. What made you go with separate scripts instead
> of Rake tasks? Just the amount of code required?
>
> I was able to build a gem and tarball without too much trouble at all.
> Not having dependencies (e.g., having SPEC and ChangeLog built when
> do/package is invoked) might lead to some confusion because you need
> to execute things in a certain order but other than that everything
> looked good.
I wanted to see how it feels without Rake.
Otherwise, we could strip down the Rakefile too.