In addition to Matthew's suggestions, be sure to list your extension
in the Weewx
Wiki <> so people can find it!


On Sat, Sep 17, 2016 at 4:06 AM, mwall <> wrote:

> On Saturday, September 17, 2016 at 5:07:03 AM UTC-4, Darryn Capes-Davis
> wrote:
>> IMPORTANT: If you wish to give it a go you need the latest which
>> was committed today. This is why I am sharing just in development group for
>> now.
>> Some questions:
>> 1. Does the extension cut the mustard as far as installer etc.?
>> 2. Where to commit this code. Leave it in my own fork or can we commit
>> back to master weewx as an extension?
>> 3. If an extension needs master weewx code to be patched, what is the
>> best way to do? Include a patch in the extension installer, assuming it
>> will be updated by a future update as well?
> darryn,
> you do not need to distribute weewx source code with your extension.  in
> this case, the only thing you need to publish is the opsgenie folder.  i
> typically publish each extension as a separate git repository, prefixed
> with 'weewx-'.  so in this case you could do it as the repository
> if your extension requires specific features/function in weewx, then test
> for it.  the most generic approach is to use a version check in the
> extension itself.  almost every extension listed in the weewx wiki does
> this.  see the check for weewx.__version__ and 'UnsupportedFeature'
> exception near the top of the code.
> in, is there some reason that you defined the 'config' as both
> a dict and configobj?  is there a reason that you did not simply specify it
> all inline?
> the best answer to your "does it cut the mustard" is to try it.  can you
> install your extension on a weewx installation using wee_extension?
> m

Reply via email to