Mailinglist Archive: yast-devel (144 mails)

< Previous Next >
Re: [yast-devel] Discussion - How should look new module written in ruby
On Thu, 01 Aug 2013 11:03:33 +0200
David Majda <dmajda@xxxxxxx> wrote:

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.

Thanks for making it more clear. I agree that some standardization
would be nice.


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 Makefile.am.common
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?

Well, even now we use two autotools + cmake. But I found it annoying as
yast have few specifics and we need to have helpers for such specifics
in both of build tools. So It is not strictly necessary, but it will be
really helpful.


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

I think that Rake can do both and we should unify it -
https://github.com/joeyates/rake-builder and
http://stackoverflow.com/questions/4272727/rakefile-rules-in-c-project


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


Yes, we can try it. Of course first part is if we want change old code
or use rake for new one or unify it, as it include a lot of file.

Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation