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/a0b38c046e6e4086a986047d0d7cd5d155af5024/src/lib/packager/clients/pkg_finish.rb). > > * 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
signature.asc
Description: Digital signature
