Hello, On Jun 19 16:49 Lukas Ocilka wrote (excerpt):
As I've been implementing new module written in Ruby only (https://github.com/kobliha/yast-services-manager), I've found out I actually can't use many generic libraries because they access the system directly omitting SCR. ... Do you have any idea how we could achieve that with the new YaST? I'd like to have something like:
SCR.Run do <ruby code> end
Regardless how it will be implemented, what you say is basically: Even after YCP was replaced by Ruby in YaST, arbitrary contributors cannot just do Ruby programming as usual to contribute something to YaST. This could become a major stumbling block for potential new contributors when their first contributions gets usually rejected because they did usual Ruby programming with generic Ruby calls that access the system directly omitting SCR. This means that even after YCP was replaced by Ruby, YaST sources are not usual Ruby programs but a special YaST-specific kind of Ruby programs. In the end it means the YaST-specific programming language YCP will be replaced by a new YaST-specific dialect of Ruby. Obviously a YaST-specific dialect of Ruby is much better than the YaST-specific programming language YCP. I like to point out that this fact must be made very clear from the beginning so that potential new contributors know it in advance before they start programming Ruby for YaST and understand the reasoning behind. I assume some potential new contributors are probably against the whole idea behind SCR (target system can be different than the system where the Ruby code runs) and think that this is needless overcomplicated. Therefore I like to have it discussed here in advance if it is possible to drop the whole idea behind SCR. Perhaps for "normal" YaST configuration modules the idea behind SCR is really needless overcomplicated? If a user likes to use a YaST configuration module to configure something on system A he must simply install all what this YaST configuration module needs to run on that system A.
From my current point of view I don't see what could be wrong with such a requirement because all other software has the same requirement.
In contrast YaST components that are needed during system installation require the idea behind SCR (because target system is in a mounted directory or in the matching chroot environment). Perhaps it is sufficient to require the YaST-specific dialect of Ruby only for YaST components that are needed during system installation but not for "normal" YaST configuration modules? My idea behind is that I assume that potential new contributors are usually interested in "normal" YaST configuration modules and not so much in the YaST core system installation components. It is like user-space software programming versus kernel programming. For kernel programming one expects special restrictions but not for user-space software programming. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org