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

Urabe,


On Thu, Sep 9, 2010 at 9:52 PM, Urabe Shyouhei <[e-mail]> wro=
te:
> I'm off today so sorry if I missed some mails.
>
> (2010/09/10 6:53), Ryan Davis wrote:
>>> But, Urabe san said, full release is needed even if "gem update"
>>> can be used.
>>
>> Then we need to change Urabe's mind. I think his argument does more harm=
 than good by delaying fixes in order to coordinate full releases. If ruby+=
gem installs do an automated update at the end of install, then there is NO=
 reason why security fixes should be delayed for full releases.
>
> 1) Being able to do "gem update" on stdlibs seems to be a good thing to h=
ave.
> I'm not against on that point now.
>
> 2) Besides that, every security issues should be addressed on our canonic=
al
> distributions, because:
>
> 2-1) Not all of ruby users use gem. =C2=A0A Linux system without internet
> connection might not be practical, but a ruby installation without one is=
 a
> real usage today.
>

But, our make script can gather the gems - perhaps a call to
rubygems.org and grab  a manifest or package of blessed libs, then put
them into the release tarball. As Ryan and others have pointed out,
it's then a matter of calling gem install blessed/*.gem - not an
operation that should require the internet.

> 2-2) I don't think we (core team) can handle occasional updates of such g=
ems
> like Debian does. =C2=A0We ought to miss something.
>
I think the core team can do what a good core team should: delegate.
Once there's a list of blessed gems, it's up to those maintainers to
ensure that their code is ready to release as per the RM's
instructions. This sort of thing could easily be built into
rubygems.org if desired - a tool to track gems ready for packaging.

> 3) Anyway, you might be surprised to hear (esp. from me) that a full rele=
ase
> is not a real problem. =C2=A0To make a release is as easy as "make dist".=
 =C2=A0The real
> headache is to coordinate one. =C2=A0And I suspect that coordination will=
 not leave
> our hands... =C2=A0Who wants to nurse WEBrick?
>

I'll happily help (as I am sure many others on this list would) corral
and co-ordinate people to get stuff release-ready. It can also be
fairly easily added to rubygems.org as mentioned, since all the core
metadata could/would exist there.

Regarding webrick: isn't it time for that lib to die? We now have
rack, mongrel, thin, unicorn and many others all doing a much finer
job of serving the web. Perhaps it's time to take a very critical look
at stdlib and see what stands up to today's developer needs: we have
already identified many libraries which are either too limited in
scope or performance to meet the needs of today.

`gem install webrick` could perhaps have a notice showing deprecation
and a link to better alternate gems:

%> gem install webrick

Successfully installed webrick
1 gem installed

** Notice: WEBrick is now considered obsolete. Perhaps try installing
one of these: [thin, rack, unicorn]? **

>
> In one word: a full release is needed anyway and it will not make a fix d=
elay.
>

In another: supplying stdlib as gems permits authors to more easily
gather feedback from user testing and a more rigorous RC testing
process. Full releases are not needed to support testing stdlib gems,
therefore we will get more testing and greater deployment experience
for our stdlib before releases.

and another: stdlib gems permit operations engineers and developers to
cherry-pick specify the parts of ruby that they need for their
applications, limiting the amount of monkey-patching risk that comes
with a wider set of libraries (something I believe Matz is working in
2.0 to better encapsulate).

one more: all of the cons so far appear to be phrased as technical
hurdles, and we're all developers -- so it should be surmountable? :)

--james