Re: ITP: golang-github-choueric-cmdmux -- Package cmdmux implements a command parser and router for terminal programme.
On Tue, 7 Feb 2017 13:23:24 +0800
Haishan Zhou <zhssmail@gmail.com> wrote:
> * Package name : golang-github-choueric-cmdmux
[...]
> * URL : https://github.com/choueric/cmdmux
> * License : GPL-3.0
Are you aware of the fact that usage of GPL is questionable *library*
Go code because a) most of Go programs are statically linked, and
b) this makes any Go code using a GPL-ed library required to use GPL
as well? That's why most of Go code is released under MIT or other
permissive libraries like that one.
[...]
> Description : Package cmdmux implements a command parser and
> router for terminal programme.
OK, so in year 2013, there already were circa 10 packages implementing
"advanced" parsing of command-line arguments for Go programs as [1]
suggests, and since then their developers did not sit on their hands ;-)
Of those, 10, at least [2] (which is now known as [3]) appears to have
gotten considerable traction in the community (~ 230 packages
importing it according to godoc.org) and has an ITP bug filed [4].
[5] has an ITP bug [6], too.
> It helps build terminal programmes which have many sub-commands. By
> registering a pair of command and handler, such as "build kernel" and
> buildKernelHandler(), the programme can invoke this handler when the
> command line is like:
>
> "./programe build kernel"
While I'm not the native speaker, I'd say modern english uses the word
"program" to refer to computer program, while "programme" is a word
specific to British english typically used to refer to some sort of
schedule of the parts of some large event -- like in "the programme
of a festival".
> Highlights include:
>
> - It is able to print the commands tree like programme "tree" does.
> - It is able to generate the bash completion file from the commands
> tree.
The package seems to lack one crucial feature: it's impossible to get
help on subcommands -- which is a must-have for any "advanced CLI"
package. The ability to do tree-style display of the CLI synopsis
and HTTP-router-like setup of subcommand handlers are nice as a code
golf example but otherwise are of questionable value: the tree-style
display is not used by any existing program I know of so it will be
puzzling for the users; the second feature might attract certain
developers but I fail to see clear gains it's able to provide to them.
So, in the end, you're about to package a library which is currently
used by no packages external to it, and vasty more feature-complete
alternatives exist. Hence do we need it in the archive?
Considering how Go ecosystem works (most project make direct use of
external libraries--typically by means of vendoring them), wouldn't it
be better to first get traction for your package "in the wild" before
pushing it into Debian?
That is, announce it on golang-nuts, on the /r/golang subreddit, maybe
somewhere else and see if it flies at all first.
1. https://dave.cheney.net/2013/11/07/subcommand-handling-in-go
2. https://github.com/codegangsta/cli
3. https://github.com/urfave/cli
4. https://bugs.debian.org/829459
5. https://github.com/google/subcommands
6. https://bugs.debian.org/821901
7. https://godoc.org/github.com/choueric/cmdmux?importers
Reply to: