Skip to Content.
Sympa Menu

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

Subject: Grouper Developers Forum

List archive

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

Chronological Thread 
  • From: "Waldbieser, Carl" <>
  • To: "Hyzer, Chris" <>
  • Cc:
  • Subject: [grouper-dev] Re: Request to make Grouper API easier to work with from scripting REPLs
  • Date: Fri, 6 May 2016 14:20:46 -0400 (EDT)


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

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,

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,
if deleteFromPointInTime and testOnly:
raise Exception("Cannot use `deleteFromPointInTime` and
`testOnly` options simultaneously.")
if deleteFromPointInTime:
PITUtils.deleteInactiveStem(stem_name, True)
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?


----- 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

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


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...


-----Original Message-----

On Behalf Of Waldbieser, Carl
Sent: Friday, May 06, 2016 12:15 PM

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 import obliterateStem
>>> obliterateStem(session, stem="path:to:stem", testOnly=False,
>>> deleteFromPointInTime=False)

But in practice this doesn't work because
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

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!

Carl Waldbieser
ITS Systems Programmer
Lafayette College


Archive powered by MHonArc 2.6.16.

Top of Page