Export package parameters in the format needed for import

[lornajane]

(I couldn't find an issue where this had already been discussed, I apologise if this is a duplicate or I'm creating noise)

My use case: copying parameters from one action to another

• when you add a database and refresh the package list, the parameters you want are on the wrong package and it's tedious to get them from one place to another
• when I wanted to test some changes to my openwhisk package without hurting what's already live, I wanted to copy the package - it's easy to redeploy but I needed the package parameters.

To get the parameters from a package, we do: wsk package get [packagename] parameters which outputs something like:

ok: got package firstpackage, displaying field parameters
[
    {
        "key": "slackURL",
        "value": "https://hooks.slack.com/blah/blah"
    },
    {
        "key": "cloudantURL",
        "value": "https://wibble-squeak-bluemix.cloudant.com"
    },
    {
        "key": "dbname",
        "value": "awesomedb"
    }
]

To supply these parameters to another package (e.g. for testing, or allowing another team member to match my config) the format I want is:

{
    "slackURL": "https://hooks.slack.com/services/blah/blah",
    "cloudantURL": "https://wibble-squeak-bluemix.cloudant.com",
    "dbname": "awesomedb"
}

With the above in a file called params.json I can then to wsk package create mypackage -P params.json.

Would it be desirable to offer this format (ideally without the extra verbose output as the first line as we have now) as an option? It's a small thing and I appreciate that patches are probably welcome, but is this a useful addition for anyone other than myself?

[akrabat]

Related to https://github.com/openwhisk/openwhisk/issues/2062 for quiet mode requirement.

[rabbah]

We have in the past considered changing the representation of parameters (and annotations) to a dictionary instead of the current array of key-value pairs. This on the one hand would also resolve this issue, but on the other is a breaking API change better left for "v2" perhaps.

[akrabat]

A forward compatible switch in v1 would be nice so that the v1 users can migrate to the v2 format before going to v2? (Unless of course, v2 is imminent…)

[lornajane]

Definitely not suggesting a breaking change, but an additional option for formatting this output. Especially if we would consider doing this for v2, then having it behind a switch to have people try it and offer feedback in the current version seems valuable. I'm just hesitating to create a patch if it won't be accepted.

[rabbah]

This is a tooling issue. It's true we can make an API change but that's not what's being requested here. Going to close/transfer to the CLI repo.