[ruby-core:32444] Re: Can we convert the standard library to gems?

On Thu, Sep 16, 2010 at 7:10 PM, James Tucker <[e-mail]> wrote:
>
> On 16 Sep 2010, at 13:23, Austin Ziegler wrote:
>
>> On Thu, Sep 16, 2010 at 10:41 AM, James Tucker <[e-mail]> wrot=
e:
>>> On 16 Sep 2010, at 10:47, Austin Ziegler wrote:
>>>> On Thu, Sep 16, 2010 at 1:59 AM, Lucas Nussbaum
>>>> <[e-mail]> wrote:
>>>>> On 16/09/10 at 11:02 +0900, James Cox wrote:
>>>>>> Still, the idea is that it should be possible to see each stdlib
>>>>>> individually must be what's important: =A0being able to distinguish
>>>>>> individual packages and make it possible for distributors and
>>>>>> implementors to roll their own rubies with a common core and custom
>>>>>> library.
>>>>> Wouldn't custom rubies and custom stdlibs give the impression that a
>>>>> distributor is distributing a crippled version of ruby, if the
>>>>> distributor provides only the core, and each stdlib library as a
>>>>> separate package?
>>>> If other distributors started embracing RubyGems in the same way that
>>>> Apple has, this wouldn't be a problem.
>>> Apple doesn't provide packages, they provide a filesystem snapshot. Thi=
s is not valid.
>>
>> Apple provided modification patches to the RubyGems team that
>> introduced (more or less) a multi-layered approach to RubyGems (e.g.,
>> system, vendor, site, local, user)
>
> That would have been sensible to support correctly, especially if hooks w=
ere provided to allow system, vendor, and site to be overruled in accordanc=
e with platform / installer policies. It's the high level of what I need to=
 do to make packaging easier for OS packagers, and I'm not just talking abo=
ut Debian here, everyone who repackages gems could do with this.
>
>> although Eric took their patch and
>> extended it to be more generic. Apple *uses* RubyGems and provides
>> certain RubyGems by default that users can then upgrade.
>
> They can install new gems with new versions, which is great, yes. What is=
n't great is that we're not wired in to provide a consistent UI, and I'm se=
eing the exact same style of issue reports coming in for bundled rdoc in ru=
by head right now, among other things.
>
>> The statement is, in fact, valid. There are distributors who choose to
>> treat RubyGems as fundamentally incompatible with what they do despite
>> the best efforts of people who are in both community camps.
>
> In it's present state, it is incompatible, or they have to hack it in a b=
ad way. Even the currently delivered approach in snow leopard is incomplete=
, and that's more a requirement for better support in RubyGems than the ven=
dors issue. The support can be generic, if sufficient time is spent analysi=
ng the wide range of different policies and requirements. A nice generic so=
lution isn't a lot to support either, in fact, I don't even think that the =
result of the current research I've been doing will even require growing th=
e code base very much at all. The refactors might even shorten and simplify=
 it, whilst also squashing a number of remaining bugs in user installs. In =
order to do this successfully existing bug reports need to of course also b=
e taken into account, and current practices on a very wide range of platfor=
ms.
>
>> Apple, on
>> the other hand, decided to treat it as something fundamentally
>> adaptable to their own processes even though there's nothing else like
>> it.
>
> Commendable, my main point is we need to make our side better, for all ve=
ndors.
>
>> I see this decision (shipping Ruby's stdlib as gems) as a step in the
>> right direction toward making everything much easier to manage.
>
> Yes, I don't disagree with the principle, I'm raising issues to help us r=
each a direction that will not introduce a slew of new problems. This area =
has a wide range of platform, policy, and technical issues that must be car=
efully addressed in order to get it right. If we don't it won't be a step f=
orward, it'll be another 2-5 years of breakage and variance on many major p=
latforms.

Correct me if I'm wrong, but we're not talking about dependencies
here, in the sense that Ruby doesn't need them to function.  we're
talking about extra features, like REXML and openssl extensions.