@anoe while working on #350 (closed), I wanted to create an executable (or some form of executable binary) to list and export the current servant routes via the servant-routes library, but that left me with the choice of adding this functionality to one of the existing executables or to add a new one.

This made me realise we have an awful lot of executable, each being very simple in isolation. Apart from the gargantext-server executable, I think it's not ideal to have so many executables, because every time we do a cabal install (or a production deploy) cabal has to build them all, which takes extra time. Plus, they just take a lot of "space" in our gargantext.cabal making it a bit hard to read and maintain.

For now, for the sake of #350 (closed) I have decided to just add yet another executable, but I think the morally correct thing to do here would be to refactor our "bin" executables:

executable gargantext-admin
executable gargantext-cli
executable gargantext-db-obfuscation
executable gargantext-import
executable gargantext-init
executable gargantext-invitations
executable gargantext-phylo
executable gargantext-upgrade
executable gargantext-phylo-profile
executable garg-golden-file-diff

Into a single one called gargantext-cli that does all sort of things. We can leverage optparse-applicative to create a nice and clean CLI interface. Optparse-applicative supports subcommands, so we could have the following commands (mock up) to do what we do now. Examples:

gargantext-cli upgrade <cmd> -- does the upgrade stuff
gargantext-cli init <cmd> -- does the init stuff
gargantext-cli db-obfuscation -- does the obfuscation stuff 
...

You get the pattern. This could potentially speed up the compilation time of the project, because rather than having to link shared objects and create elf binaries for 10 different things, this would be done only once, which seems largely more efficient.

Thoughts?

I'm happy to look into this and write migration notes appropriately. To smooth out the transition, if you rely on some of these executables during deploy (like gargantext-upgrade) we could make this backward compatible by creating bash scripts named with the old executable name but invoking the new executable.