extension system

[davidmarkclements]

We're getting a lot of cool ideas and directions we can take this, but we also need to be strict about scope and prevent bloat. To both realise the ideas, and maintain reasonable scope we should take the small core - large ecosystem approach. This requires extensibility. We already have extensibility when it comes to generators, so I'm focusing here on the shell and CLI side.

Proposing the following:

1. the core should be mainly reduced to an interface contract for extensions
2. each current shell and CLI command should in itself be an extension
   • e.g. there should be a fuge-ps module, a fuge-grep module, fuge-tail etc
3. we then create modules that are essentially clusters of functionality
   • e.g. current functionality could be called fuge-core which contains fuge-ps, fuge-tail, fuge-grep etc.
   • we could then create new sets - for instance fuge-debug which contains fuge-debug-shell, fuge-autopsy, fuge-flame and so forth
   • these additional sets would be extensions, possibly pulled in by fuge (wrapping npm) e.g.

  $ fuge install debug # === npm install fuge-debug into global npm fuge folder

(or maybe fuge add instead of fuge install.. or maybe there's an "apparatus" expression that's appropriate)

• ..
  • this approach would also allow for just installs of single modules within a functionality pack, according to user needs/prefs
  • e.g. instead of all the debug functionality, maybe we just want fuge install flame -
  • another thing to think about is stripping away parts, for instance fuge mutate minimal which essentially uninstalls everything, including parts of core leaving a micro-core (possibly good for general production management tooling or something)

[mcollina]

I'm not up for having an install and generate commands in fuge. I'm up for using yeoman for generation, and npm for installing things. We learned that if we wrap too much stuff into a single tool, it became hard to maintain. It's possible to iterate over all globally installed modules, or in fuge require chain.

I also think that fuge should wrap a basic sets of key components, e.g. tail, ps, etc. What we need is a common interface that accepts a fuge instance and operates on that, I'd call it fuge-core. We can use https://github.com/mcollina/unix-socket-leader (despite the name, it should work on windows too!) to detect that an instance of fuge is already running for the given project. We can use https://github.com/mcollina/tentacoli or something similar (maybe with pattern matching), on top of that socket, or just standard HTTP (with Hapi?).

[mcdonnelldean]

+1 on breaking out the tooling. I'd rather use more tools that are sharply focused.