From: elise huard Date: 2010-09-17T02:30:05+09:00 Subject: [ruby-core:32444] Re: Can we convert the standard library to gems? On Thu, Sep 16, 2010 at 7:10 PM, James Tucker wrote: > > On 16 Sep 2010, at 13:23, Austin Ziegler wrote: > >> On Thu, Sep 16, 2010 at 10:41 AM, James Tucker wrote: >>> On 16 Sep 2010, at 10:47, Austin Ziegler wrote: >>>> On Thu, Sep 16, 2010 at 1:59 AM, Lucas Nussbaum >>>> 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. >> >> 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. 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.