feat: `export --format --out` command

[jackHedaya]

Hi!

Added an export command that I think would be useful. This would let you generate environment files easily and smoothly. Would be really sweet to also have client libraries at some point.

P.S. Found this on tldr

[loderunner]

Hi @jackHedaya!

Thanks for the PR!

You're not the first to bring up this idea. I would usually recommend combining scrt list with a bit of scripting. In your case, it could be something like:

for key in $(scrt list); do echo "$key=$(scrt get $key)"; done > .env

but I do realize that it's inefficient and that exporting all values can become a common pattern.

---

The problem I have with this PR is that it couples strongly with 2 specific usages:

• using scrt for environment variables
• using .env files

I'd like to see a more versatile solution.

Do you think you could offer a solution which:

• supports multiple export formats (at a minimum: JSON, YAML, .env)
• outputs to stdout by default

?

Here would be an example usage in your case:

scrt export --format dotenv > .env

Does that sound like an acceptable solution to you?

[jackHedaya]

I'm definitely with you on supporting multiple formats but I still think we should leave an option to write to a file without using a shell.

For one, let's say scrt is being invoked by a process programmatically. It's not a fair assumption that there is a shell available to handle >.

Writing to a file is a really common use case and I think it'd be awesome to have first-class support. To me, it's all about DX 🙂

[loderunner]

Good point. Here's what I suggest:

Usage:
  scrt export [flags]

Flags:
  -f, --format string   export file format (json,yaml,dotenv)
  -o, --output string   export to file (defaults to stdout)

Example usages:

# export JSON to stdout
scrt export --format json

# export dotenv to .env
scrt export -f dotenv -o .env

Does that sound good to you?

[jackHedaya]

Sounds good! What do you propose the default option should be for format?

[jackHedaya]

I left json and yaml outputs completely flattened for now. Do you think we should output nested json and yaml?

scrt set mysecret.nested2 hello scrt set mysecret.nested world

Current:

{
   "mysecret.nested2": "hello",
   "mysecret.nested": "world"
}

Possible:

{
   "mysecret": {
        "nested2": "hello",
        "nested": "world"
    }
}

[loderunner]

Sounds good! What do you propose the default option should be for format?

No default, export format should be explicitly specified.

I left json and yaml outputs completely flattened for now. Do you think we should output nested json and yaml?

Flat structure for now is great. There is no concept of "nesting" in the store, so we shouldn't make one appear only at the export. Just a simple "string key"-to-secret mapping.

The idea does raise a question of "namespacing" secrets at some point in the future? 🤔 I'll keep the idea, and see if this answers a use case at some point.

[jackHedaya]

Great! Looks like everything should be in order.

[loderunner]

Another thought occurred to me: this will work perfectly for easily stringifiable data, but could be buggy with some binary data. Not sur JSON, YAML or dotenv support arbitrary binary strings (pretty sure there are actual breaking cases for all 3).

This is not a blocker, though. Just a limitation. I think we should add this to the documentation.

[jackHedaya]

Think we're ready to rock! Let me know what you think :)

I really appreciate your patience on this PR... this is my first time using Go!

[loderunner]

@jackHedaya it seems you're almost there, just a few failing tests. I'd love to release a new version soon with your new feature. Need any help finishing the PR ?

[jackHedaya]

That'd be great, thank you! A bit overwhelmed with midterms and schoolwork at the moment so haven't had time to figure out the last leg of Viper.