RFC: export

[b5]

Nice! Way to get this moving. A few quick thoughts:

Motivation

Qri prioritizes interop. In an ideal world, interop between environments would be seamless and require zero configuration. If Qri is interoperating with an SQL database, ideally the version of the data the user wants would appear to be in the database, behaving exactly like SQL data, without ever having to worry about Qri, except to decide what data to have.

That's a very high bar. To make seamless interop work with all of the formats, or even some of the formats, (ok, even one of the formats), we would need to way more resources than we currently have. So this brings us to exporting data.

It's worth noting that with export the priorities stay the same:

• Less configuration is better
• Prioritize the formats people use most
• We need a solid plan for export to grow to many formats

Because we store data in a repository users can directly access as files, robust export features are a requirement. A good export command should start by collating research & our interviews to identify the most common paths people use. We should make those defaults, requiring as little configuration as possible.

@osterbit has had a great line the other day of having contributions be durable. Basically, if I add metadata to a dataset, or column descriptions, we need to make Qri do everything it can to ensure those contributions survive the export process, and present in the native environment.

As an example that brings this together, we should put some thought into native support for the excel format, and how we'd get stuff like column descriptions into an excel spreadsheet.

[dustmop]

After considering it more, I changed my mind on the "--format header=yaml" versus "--format-header yaml" question. I think it's more clear and consistent this way.

[b5]

I was going to say the same thing. I like the position you landed on

[b5]

Ok we've discussed, and think this is ready to merge. IN IT GOES.