On Tue, 28 Jun 2016 12:01:05 +0200
Martin Vidner
On Tue, Jun 28, 2016 at 08:11:36AM +0200, Josef Reidinger wrote:
On Mon, 27 Jun 2016 16:36:53 +0200 Martin Vidner
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 YCP->Ruby.
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?
yes
* 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 or 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: 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
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 `require`.
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 "yast/arch"
To summarize what is weird about yast module, to an unsuspecting Ruby developer:
--- Before:
Yast.import "Arch" puts "system z" if Yast::Arch.s390
After: 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 classes:
class Yast::ArchClass < Yast::Module def s390 end end Yast::Arch = Yast::ArchClass.new
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.