Extend tool to do simple manual CLI driven updates for example of TextCards

[jornh]

To give an example of the use case - see the topic Programmatic way to update Dashboard Text Card

Is this something that you would consider being part of elevate.metabase.tools?

It looks like it could easily be built on top of for example:

elevate.metabase.tools/metabase-exporter/MetabaseApi.cs

Line 39 in dcca4c8

async Task PutCard(Card card)

How would you prefer it done. Maybe as separate .exe?

I'm considering to roll up my C# sleeves and submit a PR - but just wanted to get your opininion on this first

[mausch]

Hi @jornh , good thing you asked first :)
The scope of this project is limited to exporting/importing Metabase state, as that's what we currently need at Elevate.
We could extract the API classes to a library and publish that as a NuGet package so it could be reused in other projects, but frankly judging by the question on Discourse that would only help if the OP uses .NET (I don't think many people use the Metabase API let alone from .NET !). The Metabase API is simple enough that it can be wrapped in any language in a couple of hours.

[jornh]

Thanks for the superfast feedback! I can understand your reasoning. I agree, it is a simple API where you can quickly build some one-off solution in any language.

I was more thinking about the more people are spread across different home-grown one-off's there's also more each have to maintain over time on their own when the API changes like your #6. It's not just the sharing or not of code it's also the sharing of issue tracker etc.

Anyway, I in fact don't have an urgent need myself, just thought it could be a fun one-night hack. I'll think about the options going forward.

Thanks!

[mausch]

I was more thinking about the more people are spread across different home-grown one-off's there's also more each have to maintain over time on their own when the API changes like your #6. It's not just the sharing or not of code it's also the sharing of issue tracker etc.

Yep, what you describe here sounds like a spin-off project extracting the API classes in this repo to a separate library and maintained independently of the concrete use case of exporting/importing Metabase state (the scope of this project).

Unfortunately I wouldn't be able to afford maintaining such a project, but if anyone wants to do it they can (just added a LICENSE file).

Also for the Metabase team it would be useful to track client libraries like that somewhere in the documentation I think.