pre-boarding call

[Aaron J. Seigo]

hi all ...

While i'm working on filling in the remaining critical bits of the 
specification (which there is still a fair amount, to be honest), i'm also 
starting to sketch out what shape the tools will take.

There will be a number of tasks that should be highly automated for the user, 
including:

* creating a new project on disk (see docs/packaging.md for my thoughts there)
* generating documentation
* running tests
* fetching compile/run-time dependencies (modeled on node's npm)
* compiling code
* creating packages for distribution
* ... 

You get the picture: all the usual jobs and tasks that get in our way as 
developers ;)

For many projects this means using a large number of tools that were never 
really meant to be used together, but which tackle one type of task and 
hopefully do it well. As Qt devs we all know g++ (and others), doxygen, qmake, 
cmake, ...

Even languages like perl and python ship both a runtime as well as a doc 
generator, a package manager, etc. as separate tools.

Meanwhile, a lot of traditional middleware has been going through a 
"unification" process for tooling. The various and random iptools applications 
are now just one "ip" command with lots of capabilities; git does nearly 
bloody everything and the kitchen sink for revision control; modern package 
managers do everything in one tool (unlike debian's older apt-* tools) ...

I lean towards a single tool (i.e. named "funq") that provides all the 
necessary functionality behind one sleek tool. This won't reflect the code 
design which will be componentized, unit tested, etc. We don't want a big 
spaghetti ball of a monster, after all ;) but having one `funq` tool that 
gives one access to all the functionality is alluring to me.

The reasons / benefits I see:

* `funq help <something>` would let one learn about all parts of the system
* `funq` on its own would start a REPL, which seems elegant
* user interface consistency is more easily maintained with one tool rather 
than many
* it might feel "less scary" when there is just one tool rather than N for the 
newcomer
* reflects rather naturally the envisaged integrated/modular compiler system

Possible cons:

* could become git-level scary if the user interface is not carefully 
considered

The design I'm playing with is putting each set of functionality into its own 
library with `funq` being a thin wrapper on top of them that gives them a 
unified user interface on the command line.

Each library would optionally add grammar to the tool allowing the tool to 
naturally grow with time, and also help catch command collisions should they 
happen. So the packaging features would be in one library and add a grammar 
sth like:

	funq create project <name> <relative path>
	funq create package [<platform>]
	funq install deps
	funq list deps

I'd also like to have a second command description input method: JSON. Given 
how every language has JSON support these days, and funq gets it for free via 
Qt, having a JSON equivalent to the command line grammar would make it rather 
nicer to use from many higher level tools than cobbling together command 
lines. In this mode it would also respond with JSON, taking parsing command 
output out of the equation.

Do you prefer "one tool to rule them all" or "a suite of separately named 
tools, one per task"?

What are your thoughts on what would make for an excellent command input 
system?

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://kde.org/pipermail/funq-devel/attachments/20140818/0762d4e7/attachment.sig>