August 2013 - YaST Development - openSUSE Mailing Lists

[yast-devel] Discussion - How should look new module written in ruby
by Josef Reidinger 07 Aug '13

07 Aug '13

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/Assertio… [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(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 5

[yast-devel] Kudos to the Yast text mode developers
by Alex Armstrong 06 Aug '13

06 Aug '13

I recently had occasion to use the YaST ncurses interface over ssh. I was very please that the ability existed, and quite impressed by well it worked. Keep up the good work, Alex Armstrong -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

[yast-devel] Rake tasks for Yast
by Vladimir Moravec 06 Aug '13

06 Aug '13

Hi, as it was discussed here last week, ruby ecosystem provides a build tool called Rake [1]. Rake makes use of 'tasks' which define in standard Ruby syntax and Rake DSL various specific goals, e.g. running the tests, metrics or creating the ruby gem or rpm package. To easily share the tasks' code between yast modules it would be good to have a single repository/package/gem with all common tasks, including constants and helper methods. I would propose to call it yast-rake-tasks , repository skeleton draft is available here [2] . The first tasks for tests and metricstogether with updated README file will follow soon. We have been using such approach with webyastalready [3] and it provedvery useful. There is an another repo providingpackaging tasks available here [4] . Any comments and suggestions are welcome. Vlado [1] http://rake.rubyforge.org/ [2] https://github.com/vmoravec/yast-rake-tasks [3] https://github.com/webyast/webyast/tree/master/webyast-tasks [4] https://github.com/openSUSE/packaging_tasks

1 0

[yast-devel] YaST in Ruby and string to be translated
by Andrea Turrini 06 Aug '13

06 Aug '13

Hi all, I send this mail to both os-translation and yast-devel ML since it addresses both yast development and translation, so take care of these two ML when you reply. I have just noted that the POT files for YaST have been updated, probably as the result of the conversion of YaST in Ruby. As a result, the msgid strings now contain "\\n" instead of "\n" to denote the new line inside the same msgid. For instance, in printer.pot, the current string is msgid "Started the CUPS daemon.\\nWaiting half a minute for the CUPS daemon to get ready to operate...\\n" while before it was msgid "" "Started the CUPS daemon.\n" "Waiting half a minute for the CUPS daemon to get ready to operate...\n" Now, the question is: is this change expected and wanted? Note that now we have around 3310 fuzzy and 40 untranslated strings so I think it is better to be sure that all these fuzzy strings are correct before starting fixing their translations. Best, Andrea -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

5 4

[yast-devel] YCP -> Ruby in "Press"
by Lukas Ocilka 05 Aug '13

05 Aug '13

Hi, I've been searching for some "random" opinions on the YCP -> Ruby conversion to get more feedback on what's not explained well enough, what users might feel as a possible problem, etc. Here's the list: YaST is being rewritten in Ruby; Geeko gets a nosejob [nice blog post, mostly useful comments] http://opensuseadventures.blogspot.ca/2013/06/yast-is-being-rewritten-in-ru… Suse 13.1: Yast goes Ruby [German only, summary of the "Geeko gets a nosejob"] http://www.linux-magazin.de/NEWS/Suse-13.1-Yast-goes-Ruby OpenSUSE 13.1 Switching To Ruby-Based YaST [article is just a summary, posts in forum indicate it wasn't well understood] http://www.phoronix.com/scan.php?page=news_item&px=MTM4NTI http://phoronix.com/forums/showthread.php?81155-OpenSUSE-13-1-Switching-To-… Yast is being autotranslated from YCP into Ruby [forum, useful, a bit of useless posts] http://forums.opensuse.org/english/get-technical-help-here/pre-release-beta… YaST se automaticky přepisuje v Ruby [Czech only, mostly not useful] http://www.root.cz/zpravicky/yast-se-automaticky-prepisuje-v-ruby/ From my POV, the feedback is quite good and some people see a lot new potential in our move from YCP -> Ruby. On the other hand, there are many questions mostly raised because of not enough information provided from our side. We can fix this by blogging about this theme a bit more. Thanks && Bye Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 1

[yast-devel] Problem with Ruby YaST bootloader module
by Freek de Kruijf 01 Aug '13

01 Aug '13

I generated a native system using the iso with the Ruby YaST modules. The basic generation went well. When I boot my system now I get the 13.1M3 system. However I want to boot my original 12.3 system as the default system. So I started the YaST module bootloader, but it crashed with the following message: YaST got signal 6 at YCP file /usr/share/YaST2/modules/Wizard.rb:857 /sbin/yast2: regel 431: 1732 Afgebroken $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS Unable to load library icui18n "Cannot load library icui18n: (icui18n: kan gedeeld objectbestand niet openen: Bestand of map bestaat niet)" Do I need to file a bug report in bugzilla? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 2

[yast-devel] Dropping yast2-dbus-client?
by Ladislav Slezak 01 Aug '13

01 Aug '13

Hi, I just have noticed this great pull request: https://github.com/yast/yast-storage/pull/8 It replaces the dbus agent (from yast2-dbus-client) by native Ruby DBus bindings (ruby-dbus). It looks that the agent was used only at this single place and we could drop it completely now. Do anybody else use the DBus agent? If not I vote for dropping it. -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

[yast-devel] Slight incompatibility between Ruby and YCP
by Thomas Fehr 01 Aug '13

01 Aug '13

Hi, I think I found a slight incompatibility between Ruby and YCP in YCP, I have the following code: map btrfs = GetTargetMap()["/dev/btrfs"]:$[]; map ret = filter( map p, btrfs["partitions"]:[], ``(p["uuid"]:""==uuid))[0]:$[]; which, in case of an empty list returned by filter call, relies on default parameter "$[]" after index operation. In RUby this is: btrfs = Ops.get(GetTargetMap(), "/dev/btrfs", {}) ret = Ops.get( Builtins.filter(Ops.get_list(btrfs, "partitions", [])) do |p| Ops.get_string(p, "uuid", "") == uuid end, 0, {} ) This works as before in assigning empty map to ret, but it now has the side effect of a line being written to y2log stating: [Ruby] yast/ops.rb:62 Index 0 is out of array size while the equivalent YCP code did not create any y2log entries. Is this intentional? Depending on the number of occurrences of such accesses in YCP code it could clutter y2log a lot. Tschuess, Thomas Fehr -- Thomas Fehr, SuSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Tel: +49-911-74053-0, Fax: +49-911-74053-482, Email: fehr(a)suse.de GPG public key available. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

3 3