-
Notifications
You must be signed in to change notification settings - Fork 298
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should multiple option search_list_extensions concatenate? #52
Comments
imho, concatenating would lead to even more confusion. every entry specified in weewx.conf overrides whatever is set in skin.conf. if we introduce concatenation, then we have to remember which parameters are overrides and which are concatenations. (fwiw, i've been using this approach since i first wrote the exfoliation skin) |
Then this suggests we should warn if a weewx.conf override is masking something in skin.conf. BTW, I've been meaning to ask you, why do you override in weewx.conf? Why not just put the settings in the skin's configuration file? That makes it local. |
the exfoliation skin needs to work whether or not the forecast extension is installed, so the skin.conf assumes there is no forecasting. i'm pretty sure that the report will fail if it specifies a search list extension that is not installed. so when you install the forecast extension, you need to add the search list extension to exfoliation. if you modify skin.conf then you have to propagate your changes each time to take an update to the exfoliation extension. if you specify them in weewx.conf, then exfoliation updates are trivial to apply. |
btw, the exfoliation skin no longer requires full paths to its include files. those were necessary before the chdir bug was fixed in the CheetahGenerator. |
As I think about this, I think we can make the case that search list extensions are, well..., different from other parameters. By its very nature, Cheetah uses the union of all the search lists you give it. So, if you specify an SLE in weewx.conf, then a different one in skin.conf, it would be reasonable to expect Cheetah to be able to use both of them. |
if parameters in weewx.conf are merged with parameters in skin.conf, then how does one override skin.conf with something in weewx.conf? what order will the resulting items be in? |
The extensions specified in option |
the problem with merge instead of override for search_list_extensions is that then there is no way to override. as a practical matter, the combining of options from skin.conf and weewx.conf happens outside of each generator, in class StdReportEngine. so the cheetahgenerator would have to re-read the skin.conf then re-process parameters, with a special case for search_list_extensions. or the StdReportEngine merging would have to be refactored to enable the special case of search_list_extensions. meanwhile, i added debug-level logging to cheetahgenerator that indicates exactly which objects are in the search list, as well as a list of the search list pseudo-dicts that are available for use in templates. that provides users with the ability to see the effects of their weewx.conf and skin.conf changes. |
That seems like a reasonable first step. Let's close this issue --- we can revisit if necessary. |
A user (reasonably) wanted to use the forecast search list extensions in the exfoliation skin. What was unusual is how he did it --- by overriding in
weewx.conf
:He also declared an additional SLE (the "alltime" example) in the exfoliation skin.conf, the conventional way
Unfortunately, the former masks the latter, so the tag
$alltime
did not work.Here's the thread: https://groups.google.com/d/msg/weewx-user/MlD1mTUakIA/Ai8ua22g6oUJ
I must admit, I had not thought of a user overriding
search_list_extensions
fromweewx.conf
, but it seems like a reasonable thing to do.A solution would be that the final SLE should be the concatenation of the two.
Alternatively,we could warn in the log that one is replacing the other.
The text was updated successfully, but these errors were encountered: