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. 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. 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. 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]. 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. 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. I welcome any comments, suggestions or counter-proposal. Josef [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/Assertion... [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-... [8] http://rake.rubyforge.org/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org