Grouper Developers Forum

["Waldbieser, Carl" <>]

Chris,

Can you give me an examples for GSH functions like `findSubject` or 
`getGroup`?

I'm not saying that the API can't be used from scripting languages.
What I'm trying to say is that the function-like interfaces exposed in the 
Grouper Shell don't seem to be readily available to scripting environments 
without a lot of manual mapping to the API.

For something like `getGroup(...)`, it is just a matter of knowing what part 
of the API to call:

    def getGroup(session, name, exceptionIfNotFound=True):
        """
        Get a group.
        """
        return grouper.GroupFinder.findByName(session, name, 
exceptionIfNotFound)

But for something like `obliterateStem`, you end up starting to duplicate 
some of the GSH logic (in this case, the if/else logic):

    def obliterateStem(session, stem_name, testOnly=False, 
deleteFromPointInTime=False):
        if deleteFromPointInTime and testOnly:
            raise Exception("Cannot use `deleteFromPointInTime` and 
`testOnly` options simultaneously.")
        if deleteFromPointInTime:
            PITUtils.deleteInactiveStem(stem_name, True)
        else:
            ns = grouper.StemFinder.findByName(session, stem_name, True)
            ns.obliterate(True, testOnly)

What I am looking for is a straightforward way to map Grouper Shell function 
`doBaz(...)` into a scripting environment, that doesn't require having to 
manually inspect each function.

So maybe I am looking for something like:

  thing = GrouperShellFuncs(grouperSession)
  getGroup = thing.getGroup
  obliterateStem = thing.obliterateStem
  ...

So the thing I called `GrouperShellFuncs` can set up whatever context Grouper 
might need (e.g. a session, maybe some other stuff?), but the method calls 
would basically mirror the functions available to GSH.  Would the 
builder-style classes be able to do that?

I am not so concerned whether the callable thing at the end of the day is a 
static function or something else.

Does that make it any more clear?

Thanks,
Carl


----- Original Message -----
From: "Hyzer, Chris" 
<>
To: "waldbiec" 
<>,
 

Sent: Friday, May 6, 2016 1:56:13 PM
Subject: RE: Request to make Grouper API easier to work with from scripting 
REPLs

Weve been trying to move away from static methods since we don’t want to 
deprecate old methods, and to add new params you get into override-hell.  The 
builder style classes like 

new 
GroupSave(grouperSession).assignName("stem1:a").assignCreateParentStemsIfNotExist(true).save();

Does that not work well with what you are trying to do?  We could have some 
duplication there is as well if you don’t mind a bunch of overrides...  
thoughts?

Thanks
Chris

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Waldbieser, Carl
Sent: Friday, May 06, 2016 12:15 PM
To: 

Subject: [grouper-dev] Request to make Grouper API easier to work with from 
scripting REPLs


I have a request related to Bill Thompson's "Groovy Shell For Grouper" aka 
"Grouper Shell Wrappers" project [1].
This project basically uses Java-based scripting environments to import parts 
of the Grouper API.  These 
environments have their own REPLs with readline, history, tab-complete, help, 
etc.  Each language has its own 
pros and cons, and it is a way to engage more people with the project who 
don't have a strong Java background.

I did the programming for the Jython and Clojure wrappers, and one thing that 
I was reminded of recently was
that it was not particularly straightforward to pull the existing Grouper 
Shell functions into these environments
because of the way they were implemented in the main Grouper code base.

To pick on a function at random, take `obliterateStem`.  In an ideal world, I 
could just do the following to
import the function into a Jython REPL session:

>>> from edu.internet2.middleware.grouper.app.gsh import obliterateStem
>>> obliterateStem(session, stem="path:to:stem", testOnly=False, 
>>> deleteFromPointInTime=False)

But in practice this doesn't work because 
`edu.internet2.middleware.grouper.app.gsh.obliterateStem` 
is not a static function I can import-- it is a class that requires me to 
pass in an interpreter, a 
call stack, etc. to its `invoke` method.  

So I end up emulating the guts of the class in my scripted function 
definitions.

This is workable, but it would be nice if there were some "pure functions" 
that could be imported
into scripting environments that didn't require the GSH specific arguments.

Any guidance or help the Grouper project could provide in this direction 
would be great!

Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College


[1] https://github.com/wgthom/groovysh4grouper