Export options location

[metelkin]

The issue copied from the paper discussion

openjournals/joss-reviews#3708 (comment)

@martinmodrak wrote

There is also potentially problematic design in the way the definition of export targets is part of the model specification. One could IMHO argue that there should be a separation between model definition and export targets. E.g. if I want to share my model with the community, I probably don't want to prescribe how the community will export it. Conflicting needs of different team members could lead to unnecessary version control conflicts in the export definitionsm etc. The need for --julia-only and --skip-export CLI options shows that you are struggling a bit with this design choice already.

Some (not mutually exclusive) options to consider:

Move export definitions to platform.json (presumably, I won't be sharing platform.json the same way I share model files?, i.e. two team members could share Heta code but have each their own platform?)
Allow full control of exports from the CLI (e.g. allow stuff like heta build --export "{ filepath: model, format: DBSolve }")
Keep the current system, but encourage separating export definitions and models in two files (probably by the export file including the model), codify this as a good practice (e.g. by using it in examples)
Have a make-like system, where the export definitions function as "targets" and one can specify heta build [target-list] to only build specific targets)
Generally, handling exports well seems like an important (but hard) design decision. As with the other stuff, I don't insist on this being resolved for acceptance in JOSS, just wanted to share my concerns.

[metelkin]

My current thought is that the best place for "exports" is the platform.json file.
There are still several problems here.

1. Many users are more comfortable setting all the options in one file, namely index.heta. Not all of them want to modify the platform file or to use options in the command line.
2. Based on the chosen approach we need to implement the export options into both "platform" and command line. We need to come up with CLI syntax. The @martinmodrak 's ideas are interesting.

I guess I'll try to implement the approach in the next major release. Maybe it is reasonable to allow writing in the current manner but to mark it as a deprecated way.

Using another heta file for storing exports looks like a formal way but it could also be a solution.