Improve parameter parsing

[jandamm]

See here for the initial thoughts.

Currently specifying a branch requires to also specify a location since the base pattern is:
zgenom <cmd> <repo> [location] [branch]

It would be nice to be able to express this like this:
zgenom <cmd> <repo> -b [branch]

This parsing could also be used to provide better error messages.

Since sinful defaults can be provided (location: ., branch: ___) this should be doable.

// cc @kylo252

[kylo252]

I've had my eyes on this project ko1nksm/getoptions for a while and it seems really promising.
I think it might come quite handy in here since we have a mix of different, long and short, options to deal with.

[jandamm]

Looks interesting.
It's nice that it can be used to generate the code instead of integrating into this repo.

Haven't found a yet to define flags on a sub-command basis. Because --without-submodules wouldn't make sense for all commands.

[kylo252]

Did you mean -no-submodules or is it some git native flag?

Also take a look at this included example:

[jandamm]

Correct, I meant --no-submodules which is only used for zgenom clone right now. (Mainly because the lack of a parser would make zgenom load way too long).
The screenshot you posted should cover the usage of zgenom pretty good.

[jandamm]

I think this would improve the api of Zgenom but I'm not sure how to implement it without sacrificing backwards compatibility.

Obviously we could provide a fallback for the previous api if parsing did fail. But I'm not sure if there is still a benefit of using getoptions when having to fallback to manual parsing in case there is an error.

---

Edit:
The old api would be easy to port just knowing when the old api was used instead of the new one incorrectly is difficult.

---

Edit 2:
It might just work fine since zgenom load <repo> <location> <branch> would just work as before.
Only issue could be when one of the old parameters might start with a -.
This would result in A) an error that the option is not recognized or B) cutting off the first two characters of the parameter.

Besides from that it could be checked if getoptions didn't emit an error. If yes $# should be 1 (for load). If not $# should be <= 3 and the old api could be assumed.

[jandamm]

Unfortunately getoptions uses exit internally so it does only work for functions.

The actual parsing could also be done with zparseopts which is a builtin. But this would not handle any errors or provide a usage description. It would only allow to zgenom load <repo> --branch develop instead of zgenom load <repo> . develop

[jandamm]

While the issue with exit instead of return can be fixed I'm not sure the project in its current form will greatly benefit.

• There are not many commands which have > 1 arguments (bin, clone, load and pmodule).
• Most configuration is done by environment variables instead of flags.
• Probably most users don't write the commands in the interactive shell where the help is much more useful.

In the future there might be more complex commands.
Also I'm thinking about allowing to provide configuration to the command instead of variables. *
I might reconsider getoptions then.

* this might look like this:
zgenom prezto --no-defaults
zgenom ohmyzsh --repo 'user/ohmyzsh'