Mailinglist Archive: yast-devel (144 mails)

< Previous Next >
Re: [yast-devel] Discussion - How should look new module written in ruby
Dne 1.8.2013 09:53, Josef Reidinger napsal(a):
1) for skeleton I think that skeleton should be as small as possible,
so move all repeating code to own method provided by a module (that is
nice feature of rails, you can start really quickly ). And I think we
should make clear difference between leaf module and module that can be
reused by other modules. Because often there are Yast modules that have
modules, but they use it themself exclusivelly. For such case now should
be "lib" directory where is private Yast module code such us specific
configuration logic or module specific dialogs. Advantage of such step
is that you need not care about backward compatibility, as there is no
public API and we can use all ruby features.
> 2) When module need to provide API for other modules ( so API should
> be based on requirements from other modules ) it should follow simple
> ruby
> - "Tell, don't ask" [1]. That helps with reducing of data leaks often
> seen in Yast ( when you change a map structure, you have problem
> because some modules depends on exact map structure ). The second
> nice benefit is that API will be easy to go via component system as
> there is almost no data flow.

I am not sure this can be understood by anyone beside people who talked to Josef in person about these issues already :-) I'll try to restate the idea more clearly, because I think it's pretty important. Josef, please correct my re-statement is wrong.

First, the work "module" is overloaded. It can mean 3 things:

* YaST module (a set of files roughly corresponding to a package and
a Git repo)

* YCP module (YCP file that begins with `module "foo"` declaration)

* Ruby module (Ruby syntactic construct)

YCP modules were translated into Ruby. After the translation they are quite heavy-weight, require declaring of published methods/variables and they are global/singleton in nature. They are not natural citizens in RUby world. This is the price for full compatibility with YCP and YaST component system.

The proposal is to use YCP-compatible modules only for public API of given YaST module. Anything internal to the module should be implemented in native Ruby way (using Ruby modules and classes) and placed in the "lib" directory.


I agree with the idea above and personally, I would even like to see some standardization in what goes into the "lib" directory. For example, where the models and views (in the MVC sense) are placed and how they are named.

3) No includes. Includes is relict from ycp and it should be moved to
lib as common ruby class or modules. ( perl and python also doesn't
have it )

Yes. No includes in new code.

5) testing framework. We definitively need new one, old one is really
horrible to use and fragile. Ruby provide a lot of nice test
frameworks, the well known are Test:Unit[2] ( classical test unit
framework with asserts ) and RSpec that is designed to fit nice for TDD
[3]. I personally use for a long time Test:Unit and try RSpec few
months ago and I really like RSpec, especially how tests looks like and
how nice is its output.

I would also favor RSpec. Specs written using it are very readable and can be structured nicely.

6) Documentation. For code documentation we translate comments to
YARD[4]. But there is also documentation that sits around in docbook
format. I found quite hard to write new parts of documentation and keep
it up-to-date. I found tool that can convert docbook to textual based
markdown format[5]. And I also thing that documentation should be
together with code and also examples should live with code. YARD
support it in quite nice way (support inlined markdown). See e.g.
documentation of ActiveRecord::Base which lives together code and how
it can look like [6].

I think it makes sense to use just one format for the technical documentation and YARD is a natural choice here because it's used for documentation comments already.

8) build program. YaST currently use autotools. It has few drawbacks -
it is written in different language then rest of plugins ( M4 versus
ruby now ), not so popular today ( so less people understand it,
especially in ruby community ) and not so easy to share functionality
( currently we use and other tricks ). Common ruby
build tool is Rake[8], question is if we want use it.

At least for pure Ruby YaST modules, it makes a lot of sense, but there are lot of questions. The most important ones are:

* Do we want to use unified tooling for all YaST modules, or is this
not strictly necessary?

* If we want unified tooling, do we want autotools to wrap Rake, or
Rake wrap autotools in cases where they are needed (at least C++
code)? Or can Rake do all the work?

Maybe some prototyping would be the best way to explore this area.

David Majda
SUSE Studio developer
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
Follow Ups