As I continue my exploration of serverless with OpenWhisk, today I'm going to look at the packages feature. While not terribly complex, I thought writing up my take on it and sharing some screen shots might help folks better understand the basics.

As you play with OpenWhisk, you may be wondering where exactly your actions "live". Obviously the whole point of serverless is to not worry about - you know - the server - but there is a directory of sort for your actions. You can see this yourself by simply listing your actions:

What you're seeing here is a list of every action I've created. You can see that each one begins with:

/rcamden@us.ibm.com_My Space/

This is documented in Namespaces and packages:

In Bluemix, an organization+space pair corresponds to a OpenWhisk namespace. For example, the organization BobsOrg and space dev would correspond to the OpenWhisk namespace /BobsOrg_dev

Simple enough - but you can guess that organization is going to become an issue. While you can try to name your actions with good, descriptive names, at some point you will have to start giving weird names to actions just to avoid conlicts.

This is where packages come in. Essentially, you can think of them as a subdirectory for your actions. (They do more than that, and we'll cover them in a second.)

To create a new package, you issue this command:

wsk package create NAME

Here's an example of me creating one called utils:

You can see your packages with:

wsk package list

That second package you see there was created when I was working with Cloudant back on my first post on OpenWhisk.

To see what's in a package, you simply do either:

wsk package get utils

Or:

wsk package get --summary utils

The first command returns a JSON object for your package and the second returns a more readable version. I'll show you both of these later, but first let's add an action to the package so there's actually something in it. I've got a simple action I created earlier that just echoes a name:

function main(params) {

	return {
		result: "Meow, "+params.name
	};

}

To add this to my new package, I simply do:

wsk action create utils/action1 action1.js

Again, pretty simple. Now let's look at what wsk package get returns, both the 'raw' and summary version:

As you can see, the summary version is what you'll probably always want to use at the CLI. If your curious, the generic wsk action list returns all your actions, even those within packages:

Invoking the action is the same as any other action, you simply prefix the package:

wsk action invoke utils/action1 -b -r -p name Ray

Whew. So I said this was simple, right? It is - but I like to be complete and show these things actually running. So that's the basics, but what else is there?

• Packages, like actions, can have default parameters. This allows you to specify a default for every action in the package. In case you're curious, an action's default parameter takes precedence over a package's default parameter. (Thank you to Stephen Fink@IBM for clarifying that for me.)
• The other big change is that packages can be shared with the wider world. You can specify a "shared" setting (true or false) when creating or updating a package. By making it shared, anyone can use it. To me, this is the biggest use case for packages - providing a way for you to collect related actions and then share them with others.
• And then finally, OpenWhisk has a large set of shared packages called whisk.system. They provide various utilities as well as access to common Watson APIs and other useful tools. You can browse the docs for them or use the CLI, but I'd check the docs as they are much easier to read.
• Ok, so really finally - I'll point out you can also put feeds in packages. I haven't yet blogged about triggers, feeds, and rules, because it's a bit complex and I'm still wrapping my head around it. They will be the subject of my next OpenWhisk article.