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

On 16 Sep 2010, at 13:23, Austin Ziegler wrote:

> On Thu, Sep 16, 2010 at 10:41 AM, James Tucker <[e-mail]> =
wrote:
>> 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:  being 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. =
This is not valid.
>=20
> 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 =
were provided to allow system, vendor, and site to be overruled in =
accordance 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 about 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 =
isn't great is that we're not wired in to provide a consistent UI, and =
I'm seeing the exact same style of issue reports coming in for bundled =
rdoc in ruby 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 =
bad way. Even the currently delivered approach in snow leopard is =
incomplete, and that's more a requirement for better support in RubyGems =
than the vendors issue. The support can be generic, if sufficient time =
is spent analysing the wide range of different policies and =
requirements. A nice generic solution 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 the 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 be taken into =
account, and current practices on a very wide range of platforms.

> 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 =
vendors.

> 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 =
reach 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 carefully addressed in order to get it right. If we don't it =
won't be a step forward, it'll be another 2-5 years of breakage and =
variance on many major platforms.