On 06/19/2013 07:10 PM, JiříSuchomel wrote:

V Wed, 19 Jun 2013 16:49:46 +0200 Lukas Ocilka 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

On Thu, 20 Jun 2013 12:51:22 +0200 Klaus Kaempf wrote:

* Johannes Meixner [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

On Thu, 20 Jun 2013 13:26:05 +0200 Klaus Kaempf wrote:

* Josef Reidinger [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

On Thu, 20 Jun 2013 15:14:54 +0200 Klaus Kaempf wrote:

* Josef Reidinger [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

On Fri, Jun 21, 2013 at 10:40:29AM +0200, Josef Reidinger wrote:

On Thu, 20 Jun 2013 15:14:54 +0200 Klaus Kaempf wrote:

...

* Josef Reidinger [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

On 06/21/2013 11:39 AM, Klaus Kaempf wrote:

* Arvin Schnell [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

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

Hello, On Jun 20 12:51 Klaus Kaempf wrote (excerpt):

* Johannes Meixner [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