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):
Hi,
we have now ruby and it brings a lot of features for free. I want to
write example refactoring and new skeleton for new module. And I would
like to discuss here what we should use. I think that now is good
time, because before conversion we are forced to write it itself, but
now we can choose from existing solution that is already implemented in
ruby.

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.
Does this mean we'll get an additional dir called 'lib' while the 'src'
dir will serve
for module public API? Are there some best-practice tips how to
structure that 'lib' dir
to keep the layout similar between yast modules?
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.
It would appreciate toexpandon this a bit more as I could not extract
much useful and specific information from this description and reference.
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 )

4) Exceptions. Ruby language provide us exceptions that can really
simplify method code-flow. If there is error and it is reported by
return value, then you need to explicitelly check it and go up if
needed. Exception allow to handle it when you need it and if you don't
handle it, then quickly recognize it[1b]. Current solution is that
ruby-bindings catch exceptions when exception is catch between
languages when calling modules ( so if both modules are in ruby, then it
is passed ) and when use WFM::Call ( in case of exception, it is
catched and return nil ).

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.
In case we go with RSpec we should be aware of the plans of the rspec
dev team, mainly
of the DSL "should"-based syntax change which is going to be depreciated
in the Rspec 3 . This link
is worth of reading:
http://myronmars.to/n/dev-blog/2013/07/the-plan-for-rspec-3
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 fully agree, but beside that what I'm missing is the basic
documentation or summary
shown on github index page for every yast module, it's strange not
having a short README
file in the repo root.

When discussing docs, will we be using the github wiki for the general
FAQs or HOWTOs?

7) Continuous integration. We found that our jenkings node how few
drawbacks, so we should also improve it. Lslezak have nice proposal how
to simplify it. We can just package new commit and and call `osc build`
and if it succeeds then submit new package to YaST:Head. Also if we
improve our testing we can use e.g. travis and integrate it to test all
of our pull request if it breaks test [7]. If we improve it, we can
then verify also our maintenance branches and we can share load between
more runners and dependency is mainly osc and what we need to package
sources.
Reading about integration and testing raised in my mind ideas about yast
ui testing.
Would it bring some significant positives from the yast future
perspective? If yes,
what would be the way to go, does it make sense to use e.g.
ycp-macro-player/recorder, cucumber etc
as I currently do not see into the details of how the components
communicate.

The next topic for discussion could be test coverage. The most used ruby
library here seems to be simplecov:
https://github.com/colszowka/simplecov . It should be easy to setup and
to use and it has lot of features. I'm going to try it out
with a single yast module and then report back results.

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.
Yes, please!

Thanks.
vlado

[1] http://pragprog.com/articles/tell-dont-ask
[1b] http://nedbatchelder.com/text/exceptions-vs-status.html
[2]
http://www.ruby-doc.org/stdlib-2.0/libdoc/test/unit/rdoc/Test/Unit/Assertions.html
[3] http://rspec.info/
[4] http://yardoc.org/
[5] http://daringfireball.net/projects/markdown/syntax
[6] http://api.rubyonrails.org/classes/ActiveRecord/Base.html
[7]
http://about.travis-ci.org/blog/2012-09-04-pull-requests-just-got-even-more-awesome/
[8] http://rake.rubyforge.org/

< Previous Next >
List Navigation
Follow Ups
References