Mailinglist Archive: yast-devel (66 mails)

< Previous Next >
Re: [yast-devel] Ruby code in SCR
On Thu, 20 Jun 2013 15:14:54 +0200
Klaus Kaempf <kkaempf@xxxxxxx> wrote:

* Josef Reidinger <jreidinger@xxxxxxx> [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@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >