[RFC] Support workflow without template and configuration files

[chshersh]

I'm looking at the content of the .headroom.yaml file and I believe that all that information can be detected at runtime without the need to create extra configuration file. So sensible defaults would apply.

The default content of the config file:

run-mode: add
source-paths:
  - .
template-paths:
  - headroom-templates
variables:
  author: John Smith
  email: john.smith@example.com
  project: My project
  year: '2020'

1. run-mode can be specified as a command-line argument.
2. Author and email can be guessed from the .cabal file (for Haskell projects, not sure about other languages)
3. Project name can be guessed from the .cabal file.
4. Year should be updated automatically as proposed in #29

Or maybe you can even implement the Partial Options Monoid pattern in Haskell, so only relevant information needs to be specified in the config.

[vaclavsvejcar]

@chshersh Thanks for this one, good idea in general, but the implementation could be more tricky. To your specific points:

1. True, the run-mode is kinda redundant, I was already thinking about dropping it from the YAML configuration. Will probably do in next Headroom release.
2. This would be nice to have, but it will need some more research if this is feasible for all supported file types (i.e. project types).
3. Same as above
4. Agree, let's talk about the details on #29 page.

Regarding the Partial Options Monoid - never heard about that bad boy before, but will definitely check it out.

EDIT: One more question, what exactly do you mean by workflow without the template file, do you really mean withou the folder of Mustache templates, or (in this case) without the YAML configuration file?

[chshersh]

@vaclavsvejcar A general idea I had in mind is minimization of the configuration file length and specification of only those bits of information that can be discovered at runtime or not required to be consistent with the existing metadata (for example, I guess author name and email in Haskell module headers should be consistent with the maintainer field in the .cabal file). In my mind, default settings should work for the most common case without additional effort. If course, it's not possible to support every project structure without any configuration at all, so I don't propose to remove the configuration completely, it's very useful for non-trivial projects.

One more question, what exactly do you mean by workflow without the template file, do you really mean without the folder of Mustache templates, or (in this case) without the YAML configuration file?

Sorry, my title wasn't clear enough. I meant both. If no configuration or template files present, headroom can just use the default configuration and template without the need to create those. The default module header template for Haskell is already quite reasonable.

But again, this is just a proposal and only my thoughts so far 🙂 If by design you want to have all configuration explicitly written in files, so user's will know what they'll get, that's totally okay!

[vaclavsvejcar]

@chshersh Thanks for your comment. Absolutely agree with the idea to reduce the configuration as much as possible, actually started to reimplement configuration loading using the Partial Options Monoid, really like the idea behind that (pity I didn't know about it when I started to work on Headroom). Looks that release 0.2.0.0 will be quite big rewrite 😄

Regarding the option to run Headroom without template files - I'll think about it and how to possibly implement that in best way. Agree that it could be helpful for small projects, just need to figure out how to fit it in the current workflow.

[vaclavsvejcar]

@chshersh I decided to split this issue into smaller ones, the support for running Headroom without .headroom.yaml (#40) will be probably released as part of version 0.2.1.0.

[vaclavsvejcar]

@chshersh I was thinking about this one and decided that I'll implement it as one task, as you originaly proposed, to allow workflow without the need to generate any files. For example, if you'd like to render MPL2 headers for some project, you'd be able to use something as:

$ headroom run --builtin-templates mpl2 -s /path/to/src1 -s /path/to/src2 -v "author=John Smith" -v "email=j.smith@tardis.com" -v "project=Gallifrey" -v "year=2020"

Where the --builtin-templates will make possible not to specify concrete license files using -t|--template-path=PATH.

[vaclavsvejcar]

Implemented in master, will be part of the 0.2.3.0 version. Current implementation is not as powerful as proposed (i.e. no metadata reading from .cabal file), I'll eventually implement this as part of another task due to potential complexity. For now, it's possible to use Headroom without the need to generate any files (template or configuration) just by specifying all the required stuff using command line arguments (documentation). @chshersh Please let me know if you plan to anyhow test this for your projects. Also if you plan to use Headroom for any of your project, let me know and if you wouldn't mind, I'd like to put links to them to README :-)

[chshersh]

@vaclavsvejcar Thanks for your work! Yes, I'm planning to use headroom for all my and @kowainik projects, especially if the workflow is smooth :slightly_smiling_face: Actually, let me try it just now...

[chshersh]

@vaclavsvejcar You can see my attempt to use headroom in Summoner in this PR:

• https://github.com/kowainik/summoner/pull/457

[vaclavsvejcar]

@chshersh Great, thanks, I'll check the mentioned issues in PR and let's see how we can solve them to improve Headroom to suit your requirements.

[vaclavsvejcar]

Implemented and released as part of v0.3.0.0.

• https://doc.norcane.com/headroom/v0.3.0.0/whats-new/