Design of new command "project"

[jneira]

• The idea of add a new command to etlas named project is suggested in several issues in this repo and in the main eta repo
• The common criteria for the features to be added could be:
  • They have to be the scope of the project, that is, ideally they shouldnt change any global state of the etas/eta installation and they should apply the changes for the entire project by default (although you could specify individual components if make sense apply the subcommand/flag individually)
  • The feature shouldn't fit as subcommand or flag of another command, it worths ponder for each one where could be placed
  • However always there would be present the idea of not add to much functionality in another command. Even we could duplicate some behaviour (trying to use the same code underneath).
• As the command is general enough maybe one level of subcommands could be added as second ui layer.
• The proposals mentioned etlas project had been so far:
  • Interoperability between config formats: json, dhall, cabal, gradle, maven(?) (etlas project --json #18, read dependencies from *.cabal gradle-eta#30)
    • The @rahulmutt proposal in the gradle-eta issue was add etlas project [component] --[format]
    • Another feature (more complex) could be modify a existent config file (f.e. dependencies) with the content of another one.
  • Add an option to query the files being watched by etlas new build: etlas project --watch-files eta#720
    • etlas project --watch-files

[jneira]

The actual etlas deps command maybe could be included in this one as

etlas project deps [component] --format=[dhall,cabal,gradle,maven?,default(the actual one)]

The generation of complete config files as

etlas project config [component] --format=[dhall,cabal,gradle,maven?]

And watch:

etlas project watch-files
etlas project watched-files (to make clear we are querying wich files are being watched and no telling etlas to watch any file)

[rahulmutt]

@jneira That looks good so far. The etlas deps change will break gradle-eta so we should make sure we bump the version number so that we can detect the change and use the right command.

[jneira]

@rahulmutt yeah, even we could keep the separate command one major version and mark it as deprecated, to remove it safer in the next major release.

[rahulmutt]

We can be faster than that since it's really easy to update gradle-eta and have users update as well. gradle-eta keeps track of etlas version so we just do a version check before doing the deps command.