Some thoughts on LMIShell and scripton development

Tomáš Smetana tsmetana at redhat.com
Fri Apr 5 07:46:24 UTC 2013


On Wed, 03 Apr 2013 08:14:26 -0400
Stephen Gallagher <sgallagh at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed 03 Apr 2013 02:55:28 AM EDT, Peter Hatina wrote:
> > Hi,
> > 
> > On 04/01/2013 09:16 PM, Stephen Gallagher wrote:
> >> Scriptons should follow standard Python recommendations for
> >> return values and exceptions. We should make an attempt to
> >> properly handle any expected exceptions (such as network errors)
> >> at all levels (both in scriptons and OpenLMI)
> > 
> > Wrt shell, I was not 100% sure, if to use exceptions or not. I
> > know python uses them as often as possible, but from the user point
> > of view, I wanted to avoid them (they can be turned on in the
> > running shell), because of the stack trace etc, when an error
> > occurs (are the lmishell users programmers?). Maybe I could drop
> > the code, which "traps" the exceptions and packs them into classic
> > C-return values, if we are OK with that.
> > 
> 
> 
> 
> That's a really interesting question. I was thinking that, since the
> scriptons are python code, we should aim very closely at maintaining a
> "pythonic" way of doing things. There's certainly an argument to be
> made for having the scriptons behave a little more like bash scripts,
> though.
> 
> I'd like to hear more opinions on this, ideally from people who might
> eventually consume these scriptons. What would they like to see?

I understand scriptons to be the Python modules that may eventually be
wrapped by higher-level Python scripts.  I don't think there is a way to not
to treat them as Python code.  On the other hand the "higher-level" wrappers
should behave like shell commands since those would be standard executables
meant to be called from the standard shell scripts.

About the exceptions: I would rather see them turned on in the
non-interactive mode and caught and translated to error codes when using the
shell interactively by default.  However we need to keep this behaviour
configurable (even runtime): we're targeting Python coders as well as
"ordinary admins" and these groups might have different preferences on how
the LMI Shell should behave.

Regards,
-- 
Tomáš Smetana
Platform Engineering, Red Hat


More information about the openlmi-devel mailing list