Re: What libraries to be unbundled?

This seems like a logical approach. Give the user what they expect,  
and are used to (keep the common case simple), but make it possible  
to strip it down, or replace libraries (keep the uncommon possible).

Is this technically feasible?
Would there be issues enforcing a standard set of Gems amongst all  
package maintainers?

-Tom
(long time reader, first time poster)

On 30 Jul 2007, at 19:16, Evan Phoenix wrote:

> There is also a middle ground that has not been mentioned that Chad  
> and I have discussed before. That is unbundling everything into  
> gems, but then rebundling certain gems so they ship with ruby by  
> default, but can be upgraded easily.
>
> This allows WEBrick and friends, libraries that people say are so  
> useful they must be bundled, to remain as such, but still reap the  
> benefits of being hooked into rubygems.
>
> The persistent cgi.rb problems highlight this. If a gem containing  
> cgi.rb was shipped with ruby by default, then when the cgi.rb bugs  
> had been found, people could simple upgrade that gem.
>
> Remember that the point of unbundling is to free more code for the  
> release schedule of ruby, and allow that code to flourish more on  
> it's own. Being able to easily upgrade 'shipped' code is paramount  
> to that.
>
>  - Evan Phoenix
>
> On Jul 24, 2007, at 12:26 PM, Timothy J. Wood wrote:
>
>>
>> On Jul 24, 2007, at 12:19, Mike Moore wrote:
>>> If you follow this to its logical conclusion, I think you'll end up
>>> unbundling almost the entire standard library!
>>>
>>> Precisely!
>>
>>   Indeed.  The smaller the standard library is, the more likely it  
>> is that ruby can
>> be embedded in apps like Joyent's Slingshot w/o bringing along a  
>> ton of
>> unused code.
>>
>> -tim
>>
>>
>
>