Mailinglist Archive: yast-devel (48 mails)

< Previous Next >
Re: [yast-devel] YaST2 reorganization discussion
I am quoting the markdown here:

# YaST2 reorganization

## Problems

### Namespaces

We see these problems in this area:

* Polluting the Ruby top-level namespaces with names as generic as
Installation, Packages or UI.
* Inconsistencies.
* Collisions (e.g. Storage is already a module and cannot be used
as a namespace).

Let's see some examples:

* `::Registration::UI::Dialog` vs `::UI::InstallationDialog`
* `::Installation::FinishClient` vs `Yast::PkgFinishClient`

You can see a complete example in

* PkgFinishClient lives in Yast namespace (although is located in
`lib/packages/clients/pkg_finish.rb`; more on that, later).
* It inherits from `::Installation::FinishClient`, which live
outside the YaST namespace (polluting the top-level one).

### Source code layout

About source code layout, situation is not that bad but it can be
improved. Sometimes is not straightforward to find where a
class/module is defined (it's easy enough using grep or the Github
search, but I'd prefer a more consistent/predictible way).

Although it's not mandatory, using a single class/module per file
and naming the file as the class/module (but replacing CamelCase
with snake_case) is the preferred option within the [Ruby

Going back to `PkgFinishClient`, it should live in
`pkg_finish_client.rb`. And a
`Yast::SomeModule::Clients::SomeClient` class should be defined in

### Requiring code

Steffen pointed out that if he requires `yast/storage`, he would
expect all storage code to be loaded. And he's right. If you want
to load only a class/file, you can require

### Installed code

In an installed system, all YaST2 Ruby code lives in
`/usr/share/YaST2`. That's fine for things like modules
(`/usr/share/YaST2/modules`) which are quite YaST-specific. But
from a Ruby developer point of view, libraries should live in
`/usr/lib64/ruby/yast` (or something like that).

## Proposal

### Files/Namespaces organization

IMHO the big questions are:

1) Namespacing
2) Migration from the current state

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
* Avoid `UI` namespace as it sounds too 'general' (use `Dialogs` or

* 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
* 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

* `yast2/some-name` -> new code
* Nested classes:
* Only for private APIs.

What does this mean? Above I see 3 nested classes,

* Avoid cases like the storage `Proposal` code when possible.

Sorry, I don't know this case. What is it and why is it bad?

### Tests organization


* The intention behind `module_mymodule_spec.rb` and
`client_myclient_spec.rb` naming is to make clear that they
should disappear in the future.

### From source code to installed system

Move libraries to `/usr/lib64/ruby/vendor` with symlinks from

### Requiring code (not discussed)

If we require `yast/packager`, maybe we don't want all the dialogs,
clients and that kind of stuff to be loaded. We could also define a
`yast/packager/common` file to load only common code (libraries).

Martin Vidner, YaST Team

Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
< Previous Next >
Follow Ups