Chad Fowler wrote: > Sorry...I think the issue is that this problem is actually _more_ > general than the one example here. Our whole notion of handling > platforms needs a lot of work. We did the simplest thing that worked > at the time, but I think the current state of the gem repository has > outgrown this approach. Try installing mongrel for an example. :) > > I think we need to bump "rework platform-specific gems" onto the > pre-1.0 list.
Actually, this is 100% in line with what I'm thinking. As part of the local/remote integration (which, honestly, I haven't shared a lot of my ideas yet), I would like to define a standard way of referencing a gem, sort of a URI for gems (I'm calling it GRID, for Gem Resource IDentifier). Part of the grid will be a better way of identifying platforms. For example, I think we need to differentiate between pure ruby gems (that will run anywhere) and gems with C extensions (that require a compile environment), in addition to the win32/darwin/whetever platforms. The gem command, in resolving a GRID, will be able to select only those candidates that are appropriate for a user. I have notes somewhere on how GRIDs are supposed to work, and they should be backwards compatible (more or less) with todays scheme. Now, where did I put those notes? - Jim Weirich _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
