On Sep 28, 2008, at 6:10 PM, Trans wrote:

> On Sep 28, 6:14 pm, James Gray <ja... / grayproductions.net> wrote:
>> On Sep 28, 2008, at 3:19 PM, hemant wrote:
>>
>>> Getting your library in stdlib means, you are mostly
>>> handling over reins to someone else.
>>
>> I don't think this has to be true.
>>
>> My CSV (formerly FasterCSV) library was added to the standard library
>> last December.  I have continued to maintain it since then  
>> including a
>> big rewrite of the parser to add m17n support.
>>
>> Thus, I think this depends entirely on the contributor.  I personally
>> feel a little more pressure to keep CSV running well now that it  
>> ships
>> with Ruby.  I would rather not see people saying, "That new CSV
>> library sucks!" :)
>
> Fair point. But really, would you have felt any different if FasterCSV
> were still a separate gem? Your name is pretty synonymous with
> quality.

Thanks for the compliment, but doesn't this support my point?  Some of  
us just care.

> And as a separate gem you could improve your library faster,
> on an independent release schedule.

I concede this point.  It is probably better to include a library  
after it's pretty mature and not changing as often.

>>> Bundling of many libraries within stdlib has sorta killed
>>> competetion (net/http for instance).
>>
>> FasterCSV and mini/unit were both developed with CSV and test/unit
>> being in the standard library.  They gained enough traction to  
>> replace
>> the libraries they improved upon in this release.  Again, this  
>> doesn't
>> seem to be a universal truth.
>
> That's not really true. Look at the download numbers for miniunit
> (http://rubyforge.org/frs/?group_id=1040). I wouldn't call that
> traction. It's adoption into stdlib has more to do with who's pushing
> it then anything else. That's not so say it isn't a worthy
> replacement. I think on the whole it probably is, but that lends
> itself more to my argument.

Well, I was reading that source yesterday.  I have to say the author  
is right about it being terrific code.  I think the change is worth  
it, for whatever reason we did it.

> I'd rather see third party bundles of Ruby and popular libraries,
> instead of Ruby harboring so much its own repository.

I think Ruby would be shockingly less useful if I couldn't count on  
having things like the networking libraries, IO tools like FileUtils  
and Tempfile, and WEBrick being present with every install.  It's  
worked for Perl for a long time and I feel it's working for us.

James Edward Gray II