Open Jamstah opened 10 months ago
In general, it's a good idea. And as long as the existing format is still supported, that shouldn't affect existing users.
Not too happy with "reporters" below "report".
We could do it without an additional key. By default, each immediate child (e.g. email
) of "report" has as immediate child a dict (e.g. email
has a dict with enabled
, from
, to
, ...). If we add support for a list-of-dicts below each reporter, that could do the trick:
report:
text: # Still have these for inheritance
details: true
footer: true
line_length: 75
minimal: false
html:
diff: unified
email:
- enabled: true
from: your.username@gmail.com
to: person1@domain.net
method: sendmail
tags: tag1
- enabled: true
from: your.username@gmail.com
to: person2@domain.net
method: sendmail
tags: tag2
html: true
stdout:
color: true
enabled: true
telegram: # Still support dict format
bot_token: ''
chat_id: ''
enabled: false
This would probably be the least intrusive (no new keys), and should be super simple to check (if the immediate child is a dict, treat it as a single config, otherwise if it's a list, treat it as list of multiple configs).
Certain shared/superclass configs (e.g. text
and html
) obviously wouldn't have the possibility to be specified as list, as there can only be one. Then again, what if you want to have e.g. different text
reporter configurations for each of the multiple e-mail reporters defined? This proposal doesn't support that, but maybe that's okay for a first version?
I think it's either make a compromise like either of our suggestions, or create a V2 config file format and redesign it with the new requirements in mind, supporting both formats for now.
I would probably go with a compromise and your option looks good. I'll propose an implementation based on the tagging at some point, when I next get a chance to look at it.
Great, I like the compromise (backwards compatible) variant better, because it means less disruption for existing users. And maybe you can split the possible PRs into two, once that adds multiple reporter configs, and then after that's been merged, a separate on that adds tagging on top (or I guess tagging could be done first, as these are mostly independent?).
I did tagging first because I already had that PR in flight :)
WIP on this, for after tags are merged in: https://github.com/thp/urlwatch/compare/master...Jamstah:multiple-reporters?expand=1
WIP on this, for after tags are merged in: https://github.com/thp/urlwatch/compare/master...Jamstah:multiple-reporters?expand=1
Tags is now merged if you want to tackle this, too.
Interested in thoughts of this style of config