[Rubygems-developers] The case of binary gems and Ruby versions.

Luis Lavena luislavena at gmail.com
Thu Apr 16 22:17:23 EDT 2009


On Thu, Apr 16, 2009 at 11:07 PM, Jeremy Hinegardner
<jeremy at hinegardner.org> wrote:
> On Thu, Apr 16, 2009 at 05:44:30PM -0700, Ryan Davis wrote:
>>
>> On Apr 16, 2009, at 16:15 , Eric Hodel wrote:
>>
>>> I see two solutions:
>>>
>>> Package two separate gems with an indicator in the name for 1.8 vs 1.9
>>>
>>> Package a gem with both libraries inside, and add something to
>>> require_paths for 1.8 vs 1.9
>>
>> or:
>>
>> package the gem normally (but specifying what version of ruby should be
>> mandatory) and when it uploads it goes to a versioned depot. pure ruby gems
>> go up to a shared depot, binaries go to a versioned one. gem fetch can deal
>> with this since it has the spec already. I think this should be
>> transparent... NOT as another gem source.
>
> This was my thought too.  Solve this in the repo.  Instead of having
>
>    gems/
>    latest_specs.4.8.gz
>    ...
>
> Have
>
>    gems/
>    gems/1.8/
>    gems/1.9/
>    latest_specs.4.8.gz
>
> Or something along those lines.
>
> enjoy,
>
> -jeremy
>

I agree with both, this should be solved from the server perspective, however:

1) I cannot generate both 1.8 and 1.9 cross compiled gems from my
package in an automated way, since the gem will override the previous
generated one.

2) When upload the file to rubyforge (either web-based or rubyforge
gem) I cannot upload 2 files with the same name.

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry


More information about the Rubygems-developers mailing list