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 2.1: 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 :) http://gems.github.com/ http://github.com/blog/51-github-s-rubygem-server http://ryandaigle.com/articles/2008/4/1/what-s-new... - Trevor
on 2008-04-25 20:08
on 2008-04-26 02:36
On Sat, Apr 26, 2008 at 6:08 AM, Trevor Turk <email@example.com> wrote: > it's a thought :) > > http://gems.github.com/ > http://github.com/blog/51-github-s-rubygem-server > http://ryandaigle.com/articles/2008/4/1/what-s-new... 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. -- Cheers Koz
on 2008-04-26 03:00
On Apr 25, 7:36 pm, "Michael Koziarski" <mich...@koziarski.com> wrote: > 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 reply! - Trevor
on 2008-04-27 02:51
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.
on 2008-04-27 03:15
On Sat, Apr 26, 2008 at 05:51:19PM -0700, Josh Peek wrote: > > it's a thought :) > > > > http://gems.github.com/http://github.com/blog/51-g...... > > 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. - Matt
on 2008-04-27 03:21
It looks like it will just run a build off the gem spec. No rake tasks allow :) I think it would still be possible to write one that wraps up all the components. If someone wants to write up such a spec, I'd be happy to try it out on the github server.
on 2008-04-27 15:40
On Sat, Apr 26, 2008 at 6:20 PM, Joshua Peek <firstname.lastname@example.org> wrote: > > It looks like it will just run a build off the gem spec. No rake tasks > allow :) > > I think it would still be possible to write one that wraps up all the > components. > > 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 back. 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 project. 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 rubyforge). 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. -- Chad
on 2008-04-27 18:54
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 number. 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. This code: http://github.com/wycats/merb-core/commit/7d14e7e2... generates: http://github.com/wycats/merb-core/commit/b2ffd008... Cheers G On Apr 27, 6:40 am, "Chad Woolley" <thewoolley...@gmail.com> wrote: > On Sat, Apr 26, 2008 at 6:20 PM, Joshua Peek <j...@joshpeek.com> wrote: > > 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 > project.