Add WeatherFiles plugin 0.1.0.0-alpha1

[bartmanuel]

Summary

Initial Alpha submission of WeatherFiles — an OpenCPN plugin that browses 27+ European weather models, lets the user pick an area on the chart, and downloads sliced GRIB2 files that open directly in OpenCPN's built-in GRIB display.

Backend lives at https://api.weatherfiles.com/v1 (free tier + paid plan, documented at https://developers.weatherfiles.com).

Targets

5 metadata XMLs added, all pointing at a public Cloudsmith repo (bartmanuel-fgsm/weatherfiles-alpha, OSS plan):

Platform	XML
Debian 12 x86_64	weatherfiles_pi-0.1.0.0-debian-x86_64-12-bookworm.xml
macOS Universal (signed + notarized)	weatherfiles_pi-0.1.0.0-darwin-wx32-arm64-x86_64-14.3.1-macos.xml
Windows MSVC x86 wx32	weatherfiles_pi-0.1.0.0-msvc-x86-wx32-10.0.20348-MSVC.xml
Flatpak x86_64 (KDE 25.08)	weatherfiles_pi-0.1.0.0-flatpak-x86_64-25.08-flatpak.xml
Flatpak aarch64 (KDE 25.08)	weatherfiles_pi-0.1.0.0-flatpak-aarch64-25.08-flatpak.xml

Testing

• All tarballs built from tag v0.1.0.0-alpha1 on https://github.com/bartmanuel/weatherfiles_pi/.
• macOS dylib signed with Developer ID + Apple-notarized (status: Accepted).
• Flatpak (KDE 25.08) sideload-imported and verified end-to-end on Ubuntu by the author.
• Plugin uses C++14 + opencpn-libs (api-18, pinned to current main).
• API surface: bearer-token HTTPS to api.weatherfiles.com/v1; no inbound sockets.

Plugin source

https://github.com/bartmanuel/weatherfiles_pi — main is at tag v0.1.0.0-alpha1. The repo's README.md walks through the 3-step download wizard, save-as-set, and the security model.

Happy to make any adjustments the maintainers want — first OpenCPN submission for me.

[bartmanuel]

Hi, if there is anything I can do to clarify or enhance this PR to help you process it let me know. Always ready to help get things moving!

[bartmanuel]

Friendly nudge on this one — it's my first OpenCPN submission, so I want to make sure I've routed it correctly rather than leave it sitting silently.

@jongough — since you handle the Alpha branch, you're probably the right person for a brand-new plugin going into Alpha. @rgleason / @leamas / @nohal — tagging you too in case catalog onboarding goes through one of you.

A couple of things I think are just first-time-contributor friction rather than problems with the PR:

• CI hasn't run. CI_Pull is set to run on PRs to Alpha, but because I'm a first-time contributor the workflow is waiting on a maintainer to click "Approve and run." Once someone approves it, the XML validation should go green. Happy to fix anything it flags.
• The PR itself is MERGEABLE with no conflicts — 5 metadata XMLs (Debian 12, macOS universal signed+notarized, Windows MSVC x86 wx32, Flatpak x86_64 + aarch64 / KDE 25.08), all pointing at a public Cloudsmith OSS repo.

Plugin source: https://github.com/bartmanuel/weatherfiles_pi (main at tag v0.1.0.0-alpha1). It browses 27+ European weather models, lets you box an area on the chart, and downloads sliced GRIB2 that open in OpenCPN's built-in GRIB display. C++14 + opencpn-libs (api-18), bearer-token HTTPS only, no inbound sockets.

Glad to make any adjustments you'd like. Thanks for taking a look!

[leamas]

First of all: this plugin looks interesting and I'd love to make test. Starting the workflows now.

Please note there is a way to publish a plugin catalog which bypasses the need to make a PR to this repo. This is documented in TESTING.md

EDIT: Users like me then needs to use the custom URL you have created to test.

[leamas]

Ouch... only @bdbcat can start workflows here.

[leamas]

BTW: the Flatpak targets are wrong. We can look into this later

[bartmanuel]

@leamas , @bdbcat : I noticed that my Cloudsmith free trial expired and that I fell back to Core, which doesn't allow RAW hosting. I have applied for OSS status which allows RAW on the Core plan. Will get back here when that's fixed

[leamas]

I walked through the steps to create a custom URL at https://raw.githubusercontent.com/leamas/plugins/refs/heads/bartmanuel/pr/ocpn-plugins.xml.

However, your cloudsmith problems is a roadblock. Not that big one, though: when you create a cloudsmith repo there is an option to mark it as open-source. Such repos are free, no fees are involved. But then again, there is only one chance when creating the repo. See the developer manual

Please update your repos, perhaps by deleting+ re-creating or just use some new names, and update this PR if need be.

[bdbcat]

I could approve the workflow instantly.
But this workflow does not in any way verify the Cloudsmith links. The plugin is validated for form, and the entry will be added to the specified catalog when the PR is accepted.
It should be noted that there is nothing fundamentally requiring the plugin content downloads to reside on Cloudsmith. The content (tarball containing libraries and data) could be hosted anywhere that might be more convenient for the author/maintainer. We use Cloudsmith because it is free for OpenSource projects, and has some useful features like archived history.. Just sayin...

[bartmanuel]

Thanks @bdbcat for approving the run — and for the note that the workflow validates form only and that hosting isn't tied to Cloudsmith. Good to know. (Cloudsmith approved OSS status, so the tarball hosting is now solid again).

The run surfaced a real issue: the <summary> element was 74 chars and the catalog schema (ocpn-plugin.xsd) caps it at 72, so all 5 XMLs failed validation. I've fixed it:

• Trimmed the summary to 70 chars ("Browse WeatherFiles models, slice an area, download GRIBs into OpenCPN") in all 5 metadata files — pushed to the PR branch.
• Validated locally with xmllint --schema ocpn-plugin.xsd against all 5 files — they now pass.
• Also fixed the source (SHORT_DESCRIPTION in the plugin's CMakeLists) so regenerated metadata stays within the limit.

The new push re-triggered CI_Pull but it's back to "action_required" (first-time-contributor gate). Could you approve the run once more when you have a moment? It should be green now. Thanks again!

[leamas]

I submitted a PR moving to the shipdriver template instead. This has all required builds in place besides android which needs some love related to curl.

[leamas]

@bartmanuel : All of your issues are fixed in the pending PR, which also adds more useful builds.

If you want to open a more informal communications channel many of us hangs around in Zulip, see the manual. Zulip is somewhat like Slack and easy to use.

[rgleason]

Sorry, I have been distracted with other plugins and have not responded. It appears Alec is handling this now.

[jongough]

Yes, I can see that. Unfortunately shipdriver is a moving feast which seems to be re-written on a continual basis. FE2 is a stable build that updates without constant user modifications to make it work. But.....

[bartmanuel]

@jongough, @leamas : please advise: I switched to shipdriver on advise of @leamas, but can revert to FE2 if that's preferred. Is anything holding back merging the PR now?

[leamas]

Testplugin is actually legacy. We (the project maintainers) do not recommend it for new plugins.

[jongough]

The choice of build environment is totally up to you.

[jongough]

I am not aware that FE2 (testplugin based) is 'legacy'. It works, is up to date with all build environments and is used by quite a few plugins. I am a project maintainer and recommend it for stability, ease of use, reduction in churn and 'it just works'. New versions of FE2 are released when needed and require only copying a few files which do not impact on customisations made by other developers. All changes for a plugin are maintained in the main CMakeLists.txt file.

[bartmanuel]

@jongough , @leamas, I'm not opinionated on this, so I'll leave it in the current state for now. I understand that the build platform shouldn't affect the ability to merge this PR, since it's only 5 configs pointing to already generated tarballs. Can you confirm this @bdbcat ?

[quinton-hoole]

@jongough , @leamas, I'm not opinionated on this, so I'll leave it in the current state for now. I understand that the build platform shouldn't affect the ability to merge this PR, since it's only 5 configs pointing to already generated tarballs. Can you confirm this @bdbcat ?

Having used both approaches (testplugin and shipdriver) I can highly recommend the latter, so yes, leave in it's current state (shipdriver) would be my recommendation too.

[bdbcat]

OpenCPN core is agnostic to plugin template used. You are correct. Whatever method a dev would like to use to produce the tarballs and metadata is acceptable.
The primary motivation for common templates is to ease community maintenance of plugins when, as is common, the original dev moves on to other projects.

[bartmanuel]

@bdbcat ; Thanks for the confirmation. Is all clear for merging the PR then?

[bdbcat]

Merged.

[bartmanuel]

thanks @bdbcat !