Command-line interface for Open Metadata

[Marcus Ottosson]

Hi all,

I'm mocking up a specification for a potential cross-platform CLI for Open Metadata, let me know what you think.

This is the gist of it:

# Syntax
$ [command] [key] [value] [option]

# Example
$ om name Marcus
$ om name
Marcus
$ om /address/street Blackwall Way
$ om /address/street
Blackwall Way
$ om /address
street=Blackwall Way

Let me know what you think.

Open Metadata-cli

Best,

Marcus

[Marcus Ottosson]

GitHub page for this project.

https://github.com/abstractfactory/openmetadata-cli

[Krzy Kli]

Yo!

The design seems to be nice and neat, would it though embrace all the current and future functionality of OM?

# Syntax
$ [command] [key] [value] [option]

Just from the top of my head, what if I would like to print only *.String variables for a folder?

To be honest, I really like flags, don’t mind them at all, even think that they are useful while reading other ppl code.

Designing it to be pretty and minimalistic in this case, which I think is the intend, may not be the right way to go.

Command line has it’s own magic, might be a bit clunky, all the kwargs might not fit in one line at times :)

But it is a tool for people that rather know what they are doing, and don’t go berserk with rm -rf * ;P

why not keep it old school then? :)

# Syntax
$ om [command] [args] [kwargs]

#querying for variables of type string, created by the user krzysztof, don’t include inherited variables:

$ om -q(uery) —path /tmp/path/to/my/folder —type string —user krzysztof —inherit 0

$ om -w(rite) -p /tmp/mypath/myvar —value 29 —cast float ?

etc

Thanks

kk

On Wednesday, 7 May 2014 13:33:03 UTC+1, Marcus Ottosson wrote:

[Marcus Ottosson]

Interesting idea.

My initial goal was for the cli to be a limited, quick way of adding and viewing metadata, possibly searching for it too, and inheritance could be a mere flag. As the command-line overall is less capable than Python or any full-blown programming language, I never considered covering every aspect of OM with it.

Having said that, I’m still intrigued by your example and I’m thinking if there is a way to do both. I can certainly see a use for an “advanced” use of OM via the command line, especially if it’s used from other programming languages (e.g. as an external call) or directly via shell scripts or bat files.

I can see two ways of having both.

# Either there is one `om`, for simple use, and one `oma` for advanced use.
$ om name
Marcus
$ oma -r -p /home/marcus
Marcus

# Or there is a toggle within `om`
$ om
Open Metadata-cli - Simple mode
$ om --toggle
Open Metadata-cli - Advanced mode
$ om -r -p /home/marcus

Although ideally I’d have a single one. My motivation being that it would provide a way for newcomers to get involved more easily and, once ready, head into programming-land when their requirements on control increases.

However at the other end, programming languages could wrap, or provide bindings for an advanced cli interface, which might make it less of a hassle when porting it to other languages. Heck, the cli could potentially be the main method of interacting with OM, Python being a mere binding to it, rather than the other way around.

That way, it could become compiled (and possibly quicker) and remain linear in performance across languages.

Interesting!

[Krzysztof]

I’m definitely opting for the advanced option only.

Though I would change the term advanced for normal, since that’s what people using command line are used to ;)

And if you’re worrying about newcomers, then the command line itself will not be an issue.

A nice, easy to follow documentation for how to deal with the cli for om, with a bunch of useful examples, will surely do the trick.

awesome docs = happy users !

;)

kk

[Justin Israel]

Toggling sounds really confusing because you could be in either mode at a given time and the same tool responds differently.

Why not just use subcommands, like git?

om [flags] <subcommand> [[subargs]|[subflags]]

It lets your main command have general flags that apply overall, and then subcommands that have their own specific set of flags that can be different between each subcommand:

$ om -verbose read name
$ om write name Marcus
$ om delete name -recursive
$ om list -detailed

[Marcus Ottosson]

Those are both excellent suggestions, thanks guys. Agree on the toggling, can't quite see that working in a nice manner without causing confusion. Especially when run non-interactively.

I'm admittedly somewhat in love with the simplicity of:

$ [command][key][value]
$ om key value
$ om key
value

Any suggestions on how to satisfy the advanced need without sacrificing simple use? 

What are your thoughts on having a separate command for simple versus adva.. I mean, normal use? :)

[Justin Israel]

I would have to agree with the other comment that anyone using a command line tool is going to be fine with a few flags or subcommands. So to me it seems excessive to introduce more than one executable into the environment just to have different command syntaxes.  I think it is just as simple to place a 'read'  or 'write'  subcommand in front ad a qualifier. It even is more explicit about what the command does and could prevent accidental write if they meant to read.

--
You received this message because you are subscribed to a topic in the Google Groups "Open Metadata" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-metadata/7CzX5hbEfZM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-metadat...@googlegroups.com.
To post to this group, send email to open-m...@googlegroups.com.
Visit this group at http://groups.google.com/group/open-metadata.
For more options, visit https://groups.google.com/d/optout.

[Marcus Ottosson]

Yeah, that makes sense. Thanks!

On Saturday, 10 May 2014 21:35:14 UTC+1, Justin Israel wrote:

I would have to agree with the other comment that anyone using a command line tool is going to be fine with a few flags or subcommands. So to me it seems excessive to introduce more than one executable into the environment just to have different command syntaxes.  I think it is just as simple to place a 'read'  or 'write'  subcommand in front ad a qualifier. It even is more explicit about what the command does and could prevent accidental write if they meant to read.

On May 11, 2014 3:08 AM, "Marcus Ottosson" <konstr...@gmail.com> wrote:

Those are both excellent suggestions, thanks guys. Agree on the toggling, can't quite see that working in a nice manner without causing confusion. Especially when run non-interactively.

I'm admittedly somewhat in love with the simplicity of:

$ [command][key][value]
$ om key value
$ om key
value

Any suggestions on how to satisfy the advanced need without sacrificing simple use? 

What are your thoughts on having a separate command for simple versus adva.. I mean, normal use? :)

--
You received this message because you are subscribed to a topic in the Google Groups "Open Metadata" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-metadata/7CzX5hbEfZM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to open-metadata+unsubscribe@googlegroups.com.