Mailinglist Archive: opensuse-storage (14 mails)

< Previous Next >
Re: [opensuse-storage] legacy strategy and other things
  • From: Ancor Gonzalez Sosa <ancor@xxxxxxx>
  • Date: Fri, 15 Apr 2016 12:25:39 +0200
  • Message-id: <>
On 04/15/2016 11:16 AM, Steffen Winterfeldt wrote:
On Thursday 2016-04-14 17:48, Ancor Gonzalez Sosa wrote:

On 04/14/2016 05:11 PM, Steffen Winterfeldt wrote:

(1) the current 'refinement' using Modules does not work and is somewhat

Can you please elaborate what you mean with "does not work"? For the
purpose they are being used in the existing code, they work quite well.

To add a useful #inspect/#to_s you have to modify the class itself. But
your comment below I see that hits a sore point in the ruby world.

About #inspect/#to_s

I just feel more confident using refinements than with wild monkey
patching and it's working just fine for me so far.

Currently, you have to remember to activate all kinds of refinements all
over the code. While this may count as defensive programming its also

(4) what will an external user of storage-ng 'require'?

It depends on which parts it wants to use. For example, to use the

require "storage/proposal"

I would have expected require "yast/storage".

Well, there are 2 topics here.

1) Nesting

require "storage" # provides ::Storage
require "storage/proposal" # provides ::Yast::Storage::Proposal

This is surprising... not to say plain wrong. It would be more
consistent if the second would be
require "yast/storage/proposal"
But that's how it is done in the rest of YaST. Usually "require 'foo'
brings Yast::Foo.

I'm fine if yast-storage-ng is the first module that introduces "yast"
in the path. We should open the discussion in yast-devel, though.

2) One require per functionality and one to fetch them all

It's kind of a pattern in Ruby that libraries offer something like
require "mylibrary/functionality1" # That would be proposal in our case
require "mylibrary/functionality2" # Whatever comes next

And, in addition, they offer
require "mylibrary" # This drags all possible functionalities in

From the code/files point of view this translates into
lib/mylibrary/* -> classes
lib/mylibrary.rb -> file with just a collection of requires like
require "mylibrary/functionality1"
require "mylibrary/functionality2"

I would not like to loose the opportunity to have one require per
functionality (i.e. the current "storage/proposal"). But if we solve the
nesting problem, I'm fine (even happy) with having "yast/storage" as a
drag-everything-it require.

Why do we install to /usr/share/YaST2/lib und not /usr/lib64/ruby anyway?

I don't know. To be honest.

Ancor González Sosa
YaST Team at SUSE Linux GmbH
To unsubscribe, e-mail: opensuse-storage+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-storage+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation