----- Original Message -----
On Tue, Feb 28, 2012 at 4:47 AM, Bohuslav Kabrda
<bkabrda(a)redhat.com>
wrote:
> ----- Original Message -----
>> = ruby(name) vs rubygems(name) =
>
> Here is one important reason why Gems should not provide
> ruby(name):
> The ruby(name) provides are supposed to be provided by the
> libraries, that are meant to be directly loadable with "require
> 'name'" even without Rubygems library. The Rubygems are loaded by
> default in Ruby 1.9.3, but the users may choose not to load them
> by passing "--disable-gems" option to the interpreter (either
> directly or via environment variable RUBYOPT).
> For a user, who turns of his Rubygems, a packaged Gem providing
> ruby(name) wouldn't load, while some other non-gem package
> providing ruby(name) would load, which is obviously a puzzling
> behaviour.
>
If the guidelines are to assume that people are going to be passing
--disable-gems then they must require that non-gem subpackages exist
for all gems. When a packager packages something that requires other
ruby libraries they *must* inspect the code to see whether the code
requires the gem or non-gem form. Otherwise, libraries,
applications,
and scripts will break when the user runs with the --disable-gems
option.
However, the argument that non-gem is legacy behaviour and should no
longer be represented in packaging has been made. After looking at
how rubygems have become such an integral part of the ruby ecosystem,
this seems reasonable to me but it does not just mean that the
non-gem
subpackages have been simplified away. It also means that the
Provides and Requires situation has been simplified as well. If you
want to keep the ruby()/rubygem() Provides split because people may
run ruby with "--disable-gems" then we need to make non-gem
subpackages mandatory as well.
-Toshio
A simple question: why would we mandate creating non-gem subpackages? If the developer
uses --disable-gems, then he knows he won't be able to require any gems. He may even
base his code on it:
begin
require 'mocha'
rescue LoadError
Mocha = nil
end
if Mocha then
# ...
else
# ...
end
I believe that this simple piece of code says it all. The developer may be doing something
_based on the fact that rubygems are/are not loaded_. Therefore creating non-gem
subpackages should be forbidden. Please note, that --disable-gems can be used, for
example, for use-cases where hundreds of ruby interpreters run in parallel (not requiring
rubygems can make things significantly faster in this case), so I'm not just making
all this up.
--
Regards,
Bohuslav "Slavek" Kabrda.