Thanks all for the feedback. Now have https://github.com/dcapslock/Weewx-OpsGenie with first release https://github.com/dcapslock/Weewx-OpsGenie/releases/download/v0.1/Weewx-OpsGenie.tar.gz. Will write WIKI and then release on weewx-user group.
Note: I have included a subclassed process_record() so it does not rely on the patched restx.py. On Saturday, September 17, 2016 at 11:08:04 PM UTC+10, Tom Keffer wrote: > In addition to Matthew's suggestions, be sure to list your extension in > the Weewx Wiki <https://github.com/weewx/weewx/wiki> so people can find > it! > > -tk > > On Sat, Sep 17, 2016 at 4:06 AM, mwall <mw...@users.sourceforge.net > <javascript:>> 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 restx.py >>> 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 >> https://github.com/dcapslock/weewx-opsgenie >> >> 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 install.py, 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 >> > >
