Now that github has built this gem server setup (see links below),
would it be possible to set up a gem for "rails edge" hosted on
github? This would allow you to do something like the following in
config.gem "rails-rails", :source => "http://gems.github.com/" # use
rails edge gem
I don't know if that would work, or if it would be a good idea, but
it's a thought
I'm a little hesitant to use github's edge-gem stuff when we have a
perfectly functional alternative in vendor/rails
Once it's had a chance to be battle tested, perhaps we can look into it.
Sure thing. I just thought it was an interesting idea - thanks for the
Not sure how this would work since we have a gem for each component
and all the components are in one git repo. We might have to split up
them up into different repos.
But it would be cool for people to track rails edge through gems.
Surely it'd just be a matter of having a Rake task in the top-level (or
however Github's implementing the gem creation; haven't looked yet) that ran
the gem creator for each component? I'm a bit surprised that isn't already
implemented in the Rails tree, actually.
It looks like it will just run a build off the gem spec. No rake tasks
I think it would still be possible to write one that wraps up all the
If someone wants to write up such a spec, I'd be happy to try it out
on the github server.
I believe the current tasks are somewhat customized to building and
publishing the gems on rubyforge. I've played a bit with modifying
them to build and install gems locally, but never pushed any patch
On GitHub, the question is if they are going to support multiple gems
per project, and if so, how. The approach that makes sense to me
would be to generate gems for any gemspec that is found in the
The only problem then would be how to name the gems. Currently I
think it is <user>-<repo> for the gem name, or something. This would
have to be modified to take the gem name from the specification
somehow, or maybe from the containing directory?
There would also be the issue of handling dependencies. In a gemspec,
the dependencies are specified by name. However, I'm thinking this
might break with their custom naming convention of <user>-<repo>. You
could get around this by custom-crafting the gemspecs to have the
<user>-<repo> (or maybe <user>-<subcomponent>?) format for their
dependencies, but then these gems would only be applicable to GitHub,
and not really applicable to be deployed elsewhere. In other words,
there'd be two gem build processes - one to get the custom gem names
and dependency specifications correct for github, and another to use
the plain gem names elsewhere (locally or when deploying to
This is all speculation just off of reading the github docs and
knowing how gem specs work. Have not tried anything yet, but if
someone tackles it, please publish the git repo on this list, and I'll
gladly review and help out as I can.
The naming for gems is username-gemname (as found in the gemspec) and
is not tied at all to the name of the repo.
The versioning of gems seems to be that there will be one gem per
version number in the gemspec. So if you bump the version number at
all it will generate and host a new gem. Keeping the version number
the same, while changeing something else in the project/gemspec will
force creation of a gem replacing any older gem with the same ver
The hard part with the gemspec is that you cannot use the Dir.glob()
tricks to fill out the list of files in the gemspec. You need to
either manually maintain them (impossible on rails scale) or generate
the gemspec entirely.
The merb team seems to have checked in some code to generate their
gemspec for hosting their gems on GitHub. You might want to check it
out as a starting point for doing the same for rails.
Here is my rake task: http://pastie.org/pastes/187250
It doesn’t re-generate the gemspec, it just updates the “files” and “test_files” lines with file list.