On Tue, 7 Feb 2017 13:23:24 +0800 Haishan Zhou <zhssm...@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