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

On Thu, Sep 09, 2010 at 12:45:50PM +0900, Yusuke ENDOH wrote:
> Hi,
>=20
> 2010/9/9 Aaron Patterson <[e-mail]>:
> >>  pros:
> >>   1) advantage for users: they can use "gem update" if stdlib has
> >>      an update.  Users can also use "gem remove".
> >
> > I hope this this advantage is not understated.  When stdlib has a bug,
> > we have to *live with that bug* until the next release of Ruby.  To work
> > around, people are forced to monkey patch stdlib.
> >
> > Even worse is the disadvantage to people who are stuck with a particular
> > Ruby version in production.  Many people can update gems at will, but
> > not Ruby versions.  Those unfortunate people have to live with the bug
> > _even longer_ than Ruby's release cycle.
>=20
> I can't understand your point.

People who use Ruby on managed environments.  For example, I pay for a
shared server, but I am not allowed to upgrade Ruby.  I am allowed to
install as many gems as I want, but not allowed to upgrade Ruby.

Now, I find a bug in stdlib.  What do I do?  I can't upgrade Ruby.  I
must look for alternative hosting, or find a gem that replaces the
function stdlib provides.

> When a stdlib has a fatal bug (which causes security issue), we've
> released security package.  Users can rebuild and use it.
> If stdlib is also distributed as a gem, users have easier way: "gem
> update".  This is the advantage I mentioned.
>=20
> If a user is using ruby installed via system-dependent packaging
> system (such as apt or SUSE's), the user should not use "gem update",
> but wait the distributor to update ruby package.

On a shared environment, you are at the mercy of the providers.  You
have no control.  Packaging stdlib as gems would give you control.

> Anyway, users don't have to live with that bug, I think.
>=20
>=20
> >>  cons:
> >>   1) disadvantage for the core team: developping style will get
> >>      complex.  The core team must care multiple entities: Ruby
> >>      package and stdlib gems.
> >
> > I don't think this con is true.  Development of these gems could stay in
> > the Ruby svn repository.  There is no reason to keep them in separate
> > repositories.  Gem releases could be made from the Ruby source itself.
> > Gem releases would only happen with the ruby-core member in charge of
> > that stdlib gem deems appropriate.
>=20
> I agree.  Almost all developers will not be affected by this change,
> except release managers :-)

How would release managers be affected?  If I only use ruby svn for
managing my "stdlib-gem", ruby svn *always* has the most up-to-date
version of the code,  chkbuild will always run my tests, life would
continue the same (I think).

--=20
Aaron Patterson
http://tenderlovemaking.com/