----- Original Message ----- > On Tue, Feb 28, 2012 at 4:47 AM, Bohuslav Kabrda <bkabrda@xxxxxxxxxx> > 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. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
