Mailinglist Archive: yast-devel (48 mails)

< Previous Next >
Re: [yast-devel] YaST2 reorganization discussion
On Tue, 28 Jun 2016 12:01:05 +0200
Martin Vidner <mvidner@xxxxxxx> wrote:

On Tue, Jun 28, 2016 at 08:11:36AM +0200, Josef Reidinger wrote:
On Mon, 27 Jun 2016 16:36:53 +0200
Martin Vidner <mvidner@xxxxxxx> wrote:

I am quoting the markdown here:

# YaST2 reorganization

1) Namespacing

we write proposal below for namespacing

2) Migration from the current state

we agreed we would like to start with our target state and then move
files when it is touched or when new ones will be written, so no big
bang as even path is part of API ( you require it )

OK. The risk is a halfway change and even more confusion unless rules
are documented clearly and enforced well.
An alternative is to prepare and execute a big bang like we did with

I think we should start with agile approach and try it for few modules
and if it works without issues, use it everywhere.

File organization should be a straightforward application of the
Ruby conventions to the namespacing, right?


* Use `Y2Users`, `Y2Storage`, etc. as namespace for each module
to avoid collisions. Code should be organized under:
* `Y2Users::Dialogs::SomeName`
* `Y2Users::Clients::SomeName`
* `Y2Users::Widgets::SomeName`
* and so on

So according to the rule "yast2 for new code below(*), will it be
Y2Users::Dialogs::SomeName in lib/y2_users/dialogs/some_name.rb
Yast2::Y2Users::Dialogs::SomeName in
lib/yast2/y2_users/dialogs/some_name.rb ?

the first one. yast2 is reserver for yast-yast2. We simply find better
to have module separated namespaces, so there is no risk of collisions
and Yast2::Y2Users::Dialogs::SomeName is too long to my taste, it
almost fits whole line even if used without parameters.

(for reference,
$ ruby -r active_support/core_ext/string/conversions -e 'puts
"Y2Users".underscore' y2_users
* Avoid `UI` namespace as it sounds too 'general' (use
`Dialogs` or `Widgets`).

* Write a layer so, when requiring a library, it tries to find
the constant and, if it's not found, ask the component system.
The goal is to finally avoid `Yast.import`.

So for Arch, for example:
Yast.import "Arch" # -> /usr/share/YaST2/modules/Arch.rb
require "yast/arch" # -> .../lib/yast/arch.rb
# and ruby-bindings are adapted so that
Perl # can still find it with Import

yes, if we agreed we want it. Drawback is that actually modules are
not so common ruby classes, so it can also cause some confusion, so
maybe import is better to emphasis is not common ruby code in
common location?

That is not a sufficient reason to prefer `Yast.import` over

Well, ancor object it, so I expect we are probably too affected by YCP
and he is ruby newcomer, so easier for him to see suspicious things.
But if there is agreement, then as I mentioned before, it is not
problem for me to change yast to modify require ( also note that it
always have to be require "yast" and then require modules with require

To summarize what is weird about yast module, to an unsuspecting
Ruby developer:


Yast.import "Arch"
puts "system z" if Yast::Arch.s390

require "yast/arch"
puts "system z" if Yast::Arch.s390

Classes in the Yast:: namespace (do not confuse with Yast2:: (?))
are all named with a ...Class suffix and have Yast::Module as a
superclass. What looks like class methods all over the place are in
fact instance methods on global singleton instances of these

class Yast::ArchClass < Yast::Module
def s390
Yast::Arch =

This is because YCP, the previous implementation language of YaST,
only supported a single instance of a module.

in ruby world singleton instances looks like one with Singleton mixin,
so it have instance method ;)


* Requiring YaST2 common code:
* `yast/some-name` -> legacy or Ruby bindings code

So what exactly would be the namespaces+paths for a legacy
- module
- include
- client

still same Yast as before, no changes there.

IMHO wrong:
- prevents gem packaging
- incompatible with `require "yast/arch"`

ugh, why? I do not get what is wrong with keeping modules, includes and
clients in Yast namespace? why it prevents gem packaging? and why it is
incompatible? or do you mean to move them to lib directory under yast
dir? But how to handle if some modules have Bootloader as client,
module and also include?

We just agreed that for
code in lib, we prefer to not use Yast namespace, as there is
collisions with ruby. So we use different namespace.

(*) see above

still do not get it.
< Previous Next >
Follow Ups