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](https://github.com/yast/yast-packager/blob/a0b38c046e6e4086a986047d0d7cd5d15...).
* 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 community](https://github.com/bbatsov/ruby-style-guide#one-class-per-file).
Going back to `PkgFinishClient`, it should live in `pkg_finish_client.rb`. And a `Yast::SomeModule::Clients::SomeClient` class should be defined in `lib/yast/somemodule/clients/some_client.rb`.
### 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 `yast/storage/some_class`.
### 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 `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: Before: Yast.import "Arch" # -> /usr/share/YaST2/modules/Arch.rb After 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, `Y2Users::*::SomeName`
* 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
```ruby spec clients/ dialogs/ widgets/ module_mymodule_spec.rb client_myclient_spec.rb ```
* 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 `/usr/share/YaST2/lib`.
### 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 http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu