[yast-devel] Ruby code in SCR
Hi, 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. SCR is a layer that basically allows us to read and write configuration and call commands independently on the fact whether it is bound to current or chrooted system. SCR has the knowledge about the current target built-inside and it can switch targets on-the-fly. This is especially needed for installation. There are some want-to-haves: - Installed system as small as possible (no YaST installed at all) - Using as much upstream (Ruby) libraries as possible - We must not take care about the target path itself, that can be set or changed by installer almost anywhere 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 Any ideas how to implement this? Thanks in advance Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
V Wed, 19 Jun 2013 16:49:46 +0200 Lukas Ocilka <lukas.ocilka@suse.com> napsáno:
Do you have any idea how we could achieve that with the new YaST? I'd like to have something like:
You could use Gloves, that's ruby-based, with the potential to replace SCR. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 06/19/2013 07:10 PM, JiříSuchomel wrote:
V Wed, 19 Jun 2013 16:49:46 +0200 Lukas Ocilka <lukas.ocilka@suse.com> napsáno:
Do you have any idea how we could achieve that with the new YaST? I'd like to have something like:
You could use Gloves, that's ruby-based, with the potential to replace SCR.
Yes, that's a good idea! We've already invested some time into that project and it seems to fit the needs. Any drawbacks? Any other idea? Thx Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
* Lukas Ocilka <lukas.ocilka@suse.com> [Jun 20. 2013 09:32]:
On 06/19/2013 07:10 PM, JiříSuchomel wrote:
V Wed, 19 Jun 2013 16:49:46 +0200 Lukas Ocilka <lukas.ocilka@suse.com> napsáno:
Do you have any idea how we could achieve that with the new YaST? I'd like to have something like:
You could use Gloves, that's ruby-based, with the potential to replace SCR.
Yes, that's a good idea! We've already invested some time into that project and it seems to fit the needs. Any drawbacks?
Give it a clean API and prepare to switch to a different backend if Gloves does not fit the bill. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
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
* Johannes Meixner <jsmeix@suse.de> [Jun 20. 2013 10:52]:
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.
Exactly. You still cannot use 'puts' or 'printf' to output a string to the UI, you need UI-specific calls. And the backend is no difference. Where I agree with you, is the need to explain to contributors the reason behind this decision.
Therefore I like to have it discussed here in advance if it is possible to drop the whole idea behind SCR.
And replace it by what ? Ruby printf to write (arbitrarily complex) config files ? The idea behind SCR was to provide a simple API hiding the complexity of config files from the programmer. I strongly believe this idea is still valid. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 20 Jun 2013 12:51:22 +0200 Klaus Kaempf <kkaempf@suse.de> wrote:
* Johannes Meixner <jsmeix@suse.de> [Jun 20. 2013 10:52]:
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.
Exactly. You still cannot use 'puts' or 'printf' to output a string to the UI, you need UI-specific calls. And the backend is no difference.
Where I agree with you, is the need to explain to contributors the reason behind this decision.
Therefore I like to have it discussed here in advance if it is possible to drop the whole idea behind SCR.
And replace it by what ?
Ruby printf to write (arbitrarily complex) config files ?
The idea behind SCR was to provide a simple API hiding the complexity of config files from the programmer. I strongly believe this idea is still valid.
Klaus
One idea that I use in gloves is run code in chroot. Problem is that it means, you need already system with code installed. But for me it is also valid approach something like make_proposals install_jeos chroot("/mnt") do write_configuration end But I also agree that it is quite big change. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Jun 20. 2013 13:22]:
One idea that I use in gloves is run code in chroot. Problem is that it means, you need already system with code installed. But for me it is also valid approach something like
make_proposals install_jeos chroot("/mnt") do write_configuration end
But I also agree that it is quite big change.
Well, chroot() is fine if it's called once, when the backend is initialized. A normal YaST module shouldn't even be aware to which file the backend writes. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 20 Jun 2013 13:26:05 +0200 Klaus Kaempf <kkaempf@suse.de> wrote:
* Josef Reidinger <jreidinger@suse.cz> [Jun 20. 2013 13:22]:
One idea that I use in gloves is run code in chroot. Problem is that it means, you need already system with code installed. But for me it is also valid approach something like
make_proposals install_jeos chroot("/mnt") do write_configuration end
But I also agree that it is quite big change.
Well, chroot() is fine if it's called once, when the backend is initialized. A normal YaST module shouldn't even be aware to which file the backend writes.
Klaus
Idea is that installation should drive it. SCR is implemented in way, that you must use SCR and SCR must be aware where it runs, so it is done on low level. My idea is that installation should drive it and top level module should do something like chroot.run TopLevel::Method...like chroot.run Network.write (complex_map) and whole Network code should be available on target place. So it is decision between low level call must know if it is local or remote ( benefit is that there is no required software on target system ) and high level RPC call to complete module ( benefit is that you can use common method on any level that is just called on target system ). BTW something between solution is used for System namespace that is used for perl-Bootloader that doesn't use SCR, but use libirary that call native methods like File.write. ( but work only for modules, not for clients ) Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Jun 20. 2013 13:37]:
Idea is that installation should drive it.
Agreed.
SCR is implemented in way, that you must use SCR and SCR must be aware where it runs, so it is done on low level.
Exactly. Put all the 'knowledge' into SCR and shield SCR users from this.
My idea is that installation should drive it and top level module should do something like chroot.run TopLevel::Method...like chroot.run Network.write (complex_map)
This seems to add lots of complexity (and responsability) to individual modules. Instead of chroot.run Network.write(complex_map) I'd rather see something like # global 'chroot' call, done by installer SCR.init("/mnt") ... Network.write(complex_map) and module Network # SCR init still needed if Network is run stand-alone # it's a no-op if SCR.init was called before SCR.init ... SCR.write ... end Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 20 Jun 2013 15:14:54 +0200 Klaus Kaempf <kkaempf@suse.de> wrote:
* Josef Reidinger <jreidinger@suse.cz> [Jun 20. 2013 13:37]:
Idea is that installation should drive it.
Agreed.
SCR is implemented in way, that you must use SCR and SCR must be aware where it runs, so it is done on low level.
Exactly. Put all the 'knowledge' into SCR and shield SCR users from this.
And this is where I see problem. Let consider two main use cases for community developers who want to add new module to YaST or reuse part of YaST. 1) There is already config tool for qt and have library and I want to integrate it into YaST to get all benefits like three UIs, share with other parts of YaST, reuse code in other parts or use such configuration in add-on during install. ( we already use it e.g. for dbus calls, but I see there a much more opportunities ) So what I must do is to replace all system touching calls with SCR. For me it is really big obstacle as you must change almost complete program or have problem to reuse existing library. If you use high level call, then you can just said I need config library and run my GUI. And if it is in installation in add-on, then installation ensure that library and your client code is in place and call it in chroot, so you don't need any change. 2) There is interesting part of YaST and you want to reuse without all machinery of YaST ( like studio want use it, parts reuse in WebYaST, reuse in chef etc. ) If you want to do it, you must install whole SCR machinery which is quite big (you need component system, you need few libraries, you need a lot of agents and its configuration, you need translation between various languages ). Also there is not many people that understand it. Usually this ends up with write it again from scratch and I consider it as our fail. If we use for files augeas and for running script direct calls, then it is easy to reuse it almost everywhere immediately.
My idea is that installation should drive it and top level module should do something like chroot.run TopLevel::Method...like chroot.run Network.write (complex_map)
This seems to add lots of complexity (and responsability) to individual modules.
Instead of
chroot.run Network.write(complex_map)
No it is not this way in all modules. Current work-flow is that you have part that makes proposals and that run out of chroot and then after user confirm it, you write such settings. So for me it should be handled by *installation* module modules.each { |mod| mod::Proposal() } show_gui() if (accepted) chroot("/mnt") do modules.each { |mod| mod::write_settings() } end end and in Network::Write can be Network::Write(map m) m[:network_card].each do |card| setup_card(card) end `rcnetwork restart` # or call System, or call directly Systemd or another module or Cheetah, it is up to you end So for simple modules you can use direct write or file edit, for more complex part you can use existing modules that helps you, but important is that module care about its own bussiness and need not care about layer that ensure writting in installation. I hope you see my POV, where I hope, that components should be simple and stand-alone so it can be easily reusable and we can easily reuse components from REST of world. It would be nice to have a lot of NIH modules or simple wrapper around "rest of the World" libraries. ( for me the perfect state is when there is configuration libraries from third party and we only have layer over it in YaST that coordinates relations between components and show GUI ). Josef
I'd rather see something like
# global 'chroot' call, done by installer SCR.init("/mnt") ... Network.write(complex_map)
and
module Network
# SCR init still needed if Network is run stand-alone # it's a no-op if SCR.init was called before SCR.init ... SCR.write ... end
Klaus
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Jun 21. 2013 10:40]:
On Thu, 20 Jun 2013 15:14:54 +0200 Klaus Kaempf <kkaempf@suse.de> wrote:
Exactly. Put all the 'knowledge' into SCR and shield SCR users from this.
And this is where I see problem. Let consider two main use cases for community developers who want to add new module to YaST or reuse part of YaST. [...]
Sorry for not being clear on this. When I wrote "SCR" in the above context, I meant "common backend".
If we use for files augeas and for running script direct calls, then it is easy to reuse it almost everywhere immediately.
If every YaST module uses Augeas to modify configuration files, all is fine. Then Augeas is the 'common backend'.
So for me it should be handled by *installation* module
modules.each { |mod| mod::Proposal() } show_gui() if (accepted) chroot("/mnt") do modules.each { |mod| mod::write_settings() } end end
Fully agreed. The module does not know that it is run in chroot, only the installation module has this knowledge.
and in Network::Write can be
Network::Write(map m) m[:network_card].each do |card| setup_card(card) end `rcnetwork restart` # or call System, or call directly Systemd or another module or Cheetah, it is up to you end
I struggle a lot with the explicit call to 'rcnetwork restart'. There you put explicit backend knowledge into the (resp. each) module. I'd rather see something like Backend::RestartService("network") here.
So for simple modules you can use direct write or file edit,
See my last mail to Johannes why I would not go down this path. At the end of the day, we are talking about 'best practices' here. The old YaST (partly) enforced best practices by just offering one way to access the system (via SCR). The new YaST should encourage best practices but cannot effectively prevent module developers from file.puts() Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Fri, Jun 21, 2013 at 10:40:29AM +0200, Josef Reidinger wrote:
On Thu, 20 Jun 2013 15:14:54 +0200 Klaus Kaempf <kkaempf@suse.de> wrote:
* Josef Reidinger <jreidinger@suse.cz> [Jun 20. 2013 13:37]:
Idea is that installation should drive it.
Agreed.
SCR is implemented in way, that you must use SCR and SCR must be aware where it runs, so it is done on low level.
Exactly. Put all the 'knowledge' into SCR and shield SCR users from this.
And this is where I see problem. Let consider two main use cases for community developers who want to add new module to YaST or reuse part of YaST.
1) There is already config tool for qt and have library and I want to integrate it into YaST to get all benefits like three UIs, share with other parts of YaST, reuse code in other parts or use such configuration in add-on during install. ( we already use it e.g. for dbus calls, but I see there a much more opportunities )
So what I must do is to replace all system touching calls with SCR. For me it is really big obstacle as you must change almost complete program or have problem to reuse existing library. If you use high level call, then you can just said I need config library and run my GUI. And if it is in installation in add-on, then installation ensure that library and your client code is in place and call it in chroot, so you don't need any change.
Is there actually a way to prevent developers to "bypass" SCR and simply use Ruby file operations or modules to access the system? And we shouldn't forbid others from what we do ourself, see libzypp and libstorage. Both don't use SCR. Regards, Arvin -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
* Arvin Schnell <aschnell@suse.de> [Jun 21. 2013 10:53]:
And we shouldn't forbid others from what we do ourself, see libzypp and libstorage. Both don't use SCR.
Both libraries are part of the YaST backend and (hopefully) prevent developers from calling 'rpm', 'parted' or 'mount' directly. Give the backend a nice API, provide plenty of documentation and examples, and developers will use it. No need to prevent not using it ;-) Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 06/21/2013 11:39 AM, Klaus Kaempf wrote:
* Arvin Schnell <aschnell@suse.de> [Jun 21. 2013 10:53]:
And we shouldn't forbid others from what we do ourself, see libzypp and libstorage. Both don't use SCR.
Both libraries are part of the YaST backend and (hopefully) prevent developers from calling 'rpm', 'parted' or 'mount' directly.
Give the backend a nice API, provide plenty of documentation and examples, and developers will use it. No need to prevent not using it ;-)
True ... but Installer uses `umount` anyway. Let's define it's an exception. Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hello, On Jun 21 10:40 Josef Reidinger wrote (excerpt):
It would be nice to have a lot of NIH modules or simple wrapper around "rest of the World" libraries. ( for me the perfect state is when there is configuration libraries from third party and we only have layer over it in YaST that coordinates relations between components and show GUI ).
Basically this is how the YaST printer module works. It is more or less a wrapper around CUPS' own configuration tools that provides a GUI so that unexperienced users can call CUPS' own configuration tools in the right way. The difference is that CUPS' own configuration tools are no libraries but command line tools - mainly lpinfo and lpadmin, see "How to set up a print queue in full compliance with CUPS" at http://en.opensuse.org/Archive:YaST_Printer_redesign I could have used the CUPS library libcups and re-implement what lpinfo and lpadmin do but why should I bother with low-level stuff when I have ready-to-use high-level configuration tools? How I use SCR in the YaST printer module is only by calling SCR::Execute( .target.bash_output, "commandline" ) Usually I have bash scripts that call CUPS' own configuration tools and I call those bash scripts via SCR::Execute. I need bash scripts as wrapper around CUPS' own configuration tools for good error handling and in particular to enforce an exit after a timeout so that the SCR::Execute call cannot hang up and for special features like a progress indicator, see for example /usr/lib/YaST2/bin/autodetect_printers I never understood how SCR knows that my bash scripts need to be installed on the target system so that when the YaST printer module GUI runs on another system it can run my bash scripts on the target system. But as there is not any bug report I assume it somehow works magically. 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
On 06/20/2013 03:14 PM, Klaus Kaempf wrote:
This seems to add lots of complexity (and responsability) to individual modules.
Instead of
chroot.run Network.write(complex_map)
I'd rather see something like
# global 'chroot' call, done by installer SCR.init("/mnt") ... Network.write(complex_map)
That's how it works now.
and
module Network
# SCR init still needed if Network is run stand-alone # it's a no-op if SCR.init was called before SCR.init ... SCR.write ... end
Actually, if no SCR.init (different call name in use currently) SCR automatically uses "/" (no chroot). It looks good except one thing: It doesn't solve running some Ruby code defined in the Yast library. I still have to create a special agent and call the agent. What I wanted to solve was: There is a Yast library with some business logic and nice API. In this module, I want to use another Ruby libraries, such as File/Dir to read/modify the system. Right now, I have to use SCR for accessing the system. Totally hackish solution for this: --- cut --- code = '$some_fancy_code_in_ruby' SCR::Execute( path('.ruby'), code ) --- cut --- Agent .ruby would then eval() the code. Sounds horrible but it would do the trick :) I'm not sure about proper testing though. Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 06/21/2013 01:13 PM, Lukas Ocilka wrote:
Totally hackish solution for this: --- cut --- code = '$some_fancy_code_in_ruby'
SCR::Execute( path('.ruby'), code ) --- cut ---
Agent .ruby would then eval() the code.
Sounds horrible but it would do the trick :) I'm not sure about proper testing though.
Except that it doesn't solve one (soft) requirement: - No YaST (and libs) installed on the target system Let's assume we are in installation and SCR is "mounted" to /mnt. For this case, SCR is actually chrooted to the system on /mnt and all the libs would have to be installed there. -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hello, On Jun 20 12:51 Klaus Kaempf wrote (excerpt):
* Johannes Meixner <jsmeix@suse.de> [Jun 20. 2013 10:52]:
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.
Exactly. You still cannot use 'puts' or 'printf' to output a string to the UI, you need UI-specific calls. And the backend is no difference.
No programmer expects that 'puts' or 'printf' must work to output a string to a graphical UI. The UI calls in YaST provide the obvious advantage that the programmer does not need to care about the details of the actual UI that is used by the user (ncurses / Gtk / Qt). I.e. one same code for all those UIs (by the way: this is the only thing that I really like about YCP). In contrast the YaST concept of a backend running on the target system while the actual YaST program runs on another system does not provide an obvious advantage for the programmer because first of all it makes programming more complicated because one cannot just do the usual calls to read from and write to the system.
Where I agree with you, is the need to explain to contributors the reason behind this decision.
Is there perhaps already documentation available so that novice contributors would understand the reason behind?
Therefore I like to have it discussed here in advance if it is possible to drop the whole idea behind SCR.
And replace it by what ?
I wrote "drop" because I meant "drop".
Ruby printf to write (arbitrarily complex) config files ?
All contributors are forced to use an artificial looking abstraction layer in any case even for reading and writing really simple stuff (that works everywhere except in YaST) ?
The idea behind SCR was to provide a simple API hiding the complexity of config files from the programmer. I strongly believe this idea is still valid.
This is another different idea behind SCR. But this is not what I was talking about. Generic calls to read and write config files would provide an obvious advantage when the programmer does not need to care about the details of his particular config files (as long as the config file syntax is sufficiently simple that those generic calls actually work correctly). But I know that the SCR INI agent destroyed the cupsd.conf file several times (the cupsd.conf syntax is not too complex) during the time when the YaST printer module was made by YaST developers. Theoretically it is perhaps possible to use the SCR INI agent to modify cupsd.conf but in practice the YaST developers failed to do so. This indicates that in practice there is no such thing as "a simple API hiding the complexity of config files" when the config file syntax becomes a bit complex. 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
* Johannes Meixner <jsmeix@suse.de> [Jun 20. 2013 15:04]:
No programmer expects that 'puts' or 'printf' must work to output a string to a graphical UI.
Good. And the programmer should have the same attitude when it comes to changing config files. What is understandable and accepted in terms of UI access should also hold for accessing system resources. The problem with letting programmers directly access system resources is manifold: - it adds complexity and responsibility - it makes changing single values (like "just replace the 'Listen' port in /etc/apache2/listen.conf, leaving everything else in place") hard - it will not fix the 'YaST overwrote my config changes' complaint - it's hard/impossible to detect/prevent resource conflicts - it will open up the floodgates for all kinds of strange hacks, like every programmer using his own implementation/library to access INI type files. There are probably more, the above list is just from the top of my head. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, 19 Jun 2013 16:49:46 +0200 Lukas Ocilka <lukas.ocilka@suse.com> wrote:
Hi,
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.
SCR is a layer that basically allows us to read and write configuration and call commands independently on the fact whether it is bound to current or chrooted system. SCR has the knowledge about the current target built-inside and it can switch targets on-the-fly. This is especially needed for installation. There are some want-to-haves:
- Installed system as small as possible (no YaST installed at all) - Using as much upstream (Ruby) libraries as possible - We must not take care about the target path itself, that can be set or changed by installer almost anywhere
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
Any ideas how to implement this?
Thanks in advance Lukas
Well, actually it is already solved. For any external library or any code that needs touch of system use module that wraps library. See perl-bootloader that do system touch and its wrapper[1] that is called via System namespace, that do all necessary switching [2]. I plan to document how to use System namespace in documentation after we switch to ruby ( even if this concept exists even before). Josef [1] https://github.com/yast/yast-bootloader/blob/master/src/modules/Bootloader_A... [2] https://github.com/yast/yast-bootloader/blob/master/src/routines/lib_iface.y... -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (6)
-
Arvin Schnell -
Jiří Suchomel -
Johannes Meixner -
Josef Reidinger -
Klaus Kaempf -
Lukas Ocilka