32
In CLI design, how to ask the user for a nested structured input? (lemy.lol)
submitted 7 months ago* (last edited 7 months ago) by matcha_addict@lemy.lol to c/programming@programming.dev
24 comments fedilink hide all child comments

Background

I am designing a CLI for a container build tool I am making. It uses Gentoo's Portage behind the scenes

Question

I want to give the user the ability to specify a custom package repository. The repository must have a name, URI and sync type.

custom_repo: {
    uri: 'https://...',
    name: 'custom',
    sync_type: 'git',
}

How do I have the user represent this in the CLI? keep in mind, this is not the main input and is optional.

One way is to make this only provide-able via a config file using JSON or another structured data representation. But I want to see if theres a good way to do it in the CLI

What I am thinking of: command --custom-repo uri='https://...',name=custom,sync_type=git --custom-repo ... [main input]

Is this the best way of doing this?

all 25 comments
sorted by: hot top controversial new old
[-] chris@programming.dev 17 points 7 months ago

Just pass in the name of a json file as a CLI input (or default the name and act on it if present or use it if indicated [e.g. /U == use json.config]).

[-] xmunk@sh.itjust.works 7 points 7 months ago

Yea, as a user I'd second the use of a configuration file - that approach tends to be much more convenient to use... especially since most users won't often change these values.

[-] matcha_addict@lemy.lol 7 points 7 months ago

I will definitely make that an option, but I would still want it to be invokable via CLI only if the user chooses. It makes scripting easier sometimes.

[-] bobbykjack@programming.dev 5 points 7 months ago

How about a command-line flag to name an input file, but also process input as JSON, so someone can pipe it to your command or hand-write it if they're crazy?

[-] pupbiru@aussie.zone 2 points 7 months ago

perhaps also useful in this case to document the shortcut of

<(echo ‘{…}’)

since not many people know about it, and it makes your tool work with things specified entirely on the command line rather than temp files

alternatively —config-file and —config-json or similar

making and cleaning up temp files when writing scripts is just such a massive PITA

[-] key@lemmy.keychat.org 13 points 7 months ago

If the json payload is small with finite keys you can support separate args for those keys. If you really need arbitrary json what you have described is fairly reasonable as a shorthand, similar to AWS CLI shorthand.

Honestly passing optional/advanced args as json via CLI isn't usually too bad since you can quote it with single quotes.

[-] SpaceNoodle@lemmy.world 9 points 7 months ago

Can't this all be deduced from the URI?

https://github.com/org/project.git

The .git suffix indicates git, the project name is the stem (project).

[-] Corngood@lemmy.ml 8 points 7 months ago* (last edited 7 months ago)

Nix does something like this with the protocol specifier: e.g. git+https://...

I'm not sure what name means here exactly, but it might make sense to treat that separately, like git remotes:

tool add [name] git+https://foo

[-] oscar@programming.dev 2 points 7 months ago

That is assuming it's hosted on github.

[-] SpaceNoodle@lemmy.world 0 points 7 months ago

That is an example URI.

[-] oscar@programming.dev 3 points 7 months ago* (last edited 7 months ago)

Ok, then I don't understand at all. What happens if I host my git project on https://myawesomeproject.dev/? How can the application infer anything by this URL?

[-] SpaceNoodle@lemmy.world 0 points 7 months ago

Then replace "github.com" with "myawesomeproject.dev". There's more to the URI than just the hostname.

[-] oscar@programming.dev 3 points 7 months ago

But you can't assume that it follows the github format of https://<domain>/<user>/<project>.git. In my example, I meant that you would just use that url to clone it:

git clone https://myawesomeproject.dev

One real-world example of this is ziglings.org (though it's technically just a redirect).

[-] SpaceNoodle@lemmy.world -1 points 7 months ago

That's not a GitHub format; it's a git format.

[-] oscar@programming.dev 3 points 7 months ago

No, it isn't. Git doesn't care what the url is, as long as it uses a supported transport protocol.

[-] notabot@lemm.ee 7 points 7 months ago

For something like that i'd take a parameter like this (repeated as necessary):

--custom-repo=<name>=<synctype>+<url>

for example:

--custom-repo=custom=git+https://github.com/matcha/custom

[-] nickwitha_k 2 points 7 months ago

What language? This would be simple with Python's argparse or Go's pflag.

[-] drre@feddit.de 2 points 7 months ago

I'm having the same problem. this kind of nested argument is quite annoying to program in e.g. argp. i am even thinking of using a minimal forth like parser to do this.

[-] mryessir 2 points 7 months ago

command --git-url https://... --alias myalias --svn-url http://... --alias mysvnalias

You may process it as a stack.

When reading within the program from stdin I recommend a state machine.

[-] Cwilliams@beehaw.org 2 points 7 months ago

You could read json from standard input. Ex:

echo &lt;&lt; EOF | command --read-stdin
    Some JSON
EOF
[-] MonkderZweite@feddit.ch 1 points 7 months ago

Ask the user to customize a preset.json?

[-] matcha_addict@lemy.lol 2 points 7 months ago

That is certainly one solution and I plan to make that an option. But I'd still like to make the program invokable without having to write a file.

[-] falsem@kbin.social 0 points 7 months ago

command --custom-repo-uri https://foo.com --custom-repo-name repo_name --custom-repo-sync-type git

[-] matcha_addict@lemy.lol 2 points 7 months ago

There could be multiple custom repos, so it would be difficult to know which uri goes with which repo name, and so on.

this post was submitted on 28 Jan 2024
32 points (94.4% liked)

Programming

16968 readers
269 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz