Pirate Weather keeps the Dark Sky syntax alive and publishes the processing steps

The Dark Sky shutdown created a demand for drop-in compatibility

The repository exists to solve a narrow, dated problem. The Dark Sky API shut down at the end of 2022, and a great many services were still built against its request and response syntax. Rather than invent a new shape, Pirate Weather committed to being drop-in compatible, so an existing integration can keep running after pointing at a different host. That decision defines the audience: teams that already have weather code in production and need a replacement endpoint, not people shopping for a consumer forecasting app. The second stated motivation is transparency. Government agencies publish forecast data from computational models, but the numbers are hard to consume directly, so a group of companies process that data and publish friendlier APIs, and the intermediate steps are not public or documented. The author of the README asks, somewhat pointedly, what a provider actually means by percent of precipitation. The answer here is to publish the processing steps next to the endpoint. Anyone weighing adoption should notice that this is an inspectable pipeline built on public model output, not a proprietary forecast product with a marketing story attached.

This repository holds the documentation, the service code lives elsewhere

The first thing to check before planning an install is where the code actually sits. The project points to a separate repository, Pirate-Weather/pirate-weather-code, as the public home of the API source code, and says you are able to self-host your own instance of the Pirate Weather API or just browse through the code if you are curious on how the API works. The repository under review is the primary one for the API, but it is largely the documentation and specification side. The root of the tree carries .github/, .gitignore, .readthedocs.yaml, CNAME, DevPortal/, Gemfile, LICENSE.md, PW_OpenAPI.yaml, PirateWeatherBanner.png, README.md, _config.yml, _data/, assets/, docs/, index.md, mkdocs.yml and pyproject.toml. The primary language recorded for the repository is SCSS, which fits a documentation and front-end site rather than a service runtime. The docs/ directory is linked from the project description as the place holding the API documentation. If you plan to run the service yourself, budget time for reading a second repository as well.

The OpenAPI description sits beside the site configuration

PW_OpenAPI.yaml lives in the root next to mkdocs.yml, .readthedocs.yaml, _config.yml and index.md. That placement is the clearest signal of how the project is organised: the machine readable API contract sits beside the tooling that renders the written documentation, and both come out of the same tree. mkdocs.yml and .readthedocs.yaml point to a documentation build, while CNAME and _config.yml are the kind of files that belong to a hosted site with a custom domain. The hosted documentation address is https://docs.pirateweather.net/en/latest/, so a reader is not required to build the site to see the API reference. One caveat deserves emphasis. The file listing shows PW_OpenAPI.yaml but not its contents, so its coverage of endpoints, parameters and response shapes cannot be judged from here. Open that file and the pages under docs/ and check them against the endpoints you actually need. Documentation can sit ahead of, or behind, a running service, and only the service settles that. Treat the specification as something to verify, not something to assume.

A Python build file that names a different project

The root also carries pyproject.toml, and its contents do not match the project name. The file declares a build system of flit_core==4.1.0 with the flit_core.buildapi backend, then a project called lumache, an author entry for Graziella, and a lumache email address, with version and description marked dynamic. Nothing in the README mentions lumache, and nothing suggests the weather API is distributed as a Python package from this tree. The plain reading is that this configuration belongs to some other piece of the tooling, or was carried in from a related project. Either way, do not build a deployment plan on the presence of pyproject.toml. There is no supported pip path here. The routes the project actually documents are to take the server code from the separate source repository and to register for a hosted key.

[build-system]
requires = ["flit_core==4.1.0"]
build-backend = "flit_core.buildapi"

[project]
name = "lumache"
authors = [{name = "Graziella", email = "graziella@lumache"}]
dynamic = ["version", "description"]

Getting a key and a first real look at the data

There is no install command in this repository, and the project says where to go instead. A free API key can be requested at https://pirate-weather.apiable.io/, the API documentation is published at https://docs.pirateweather.net/en/latest/, a front end for trying the data sits at https://merrysky.net, and the status page is at https://pirateweather.xitoring.io/. For a first real use the sequence is short: request a key, read the forecast endpoint in the documentation, then query it with the Dark Sky syntax your existing code already uses. The status page matters more than it sounds, because a weather service quietly serving stale model output looks exactly like one that is working. The self-hosting route is longer: clone the API source code from the pirate-weather-code repository, work out its configuration, and point your clients at your own instance. The README does not document the environment variables, the storage requirements or a deployment recipe for that path, so treat the source repository as the place to read those details before you promise a self-hosted service date.

The request ceiling is tied to recurring donations

The support section is unusual and worth reading before you rely on the hosted service. Keeping the service free and running is not free, and recurring monthly donations are what raise the API limit, which in turn allows more frequent weather refreshes. The throughput and the freshness of the data you receive are therefore coupled to funding rather than to a published pricing table. For a hobby project or a side feature, that arrangement is workable. For a production service with an availability commitment, it becomes a procurement question: the request ceiling of a free key is not a fixed documented number, and it can move with donation levels. The alternative is self-hosting the code from the separate repository, where the ceiling becomes a function of your own hardware and hosting spend. The hosted path is low effort with an unclear ceiling, the self-hosted path is the reverse trade. No per tier limit table appears in the documentation tree, so do not plan capacity around a number you remember from a forum post.

An active tree with no tagged releases

The maintenance picture is mixed in a way that affects upgrades. The repository is not archived, and the last push was on 2026-10-19, so work is landing on the tree. At the same time, the repository has no GitHub releases, which means there is no versioned artefact to pin, no release notes to read and no changelog to diff against. For a documentation and specification repository that is tolerable: the hosted API runs somewhere else, and consumers of the hosted service experience changes without pulling anything. For self-hosters it is less comfortable, because the code in pirate-weather-code is what they run, and version stability for it is not something this repository sets out. The licence field on the repository says Apache-2.0, and a LICENSE.md file sits in the root of the tree. What that licence requires of your specific deployment is a question for a qualified adviser rather than a review. The absence of releases is the real upgrade cost to plan for: expect to read commit history instead of release notes, and expect the specification to move under you.

Editorial conclusion

Adopt the hosted Pirate Weather API if you have an existing Dark Sky integration that needs a live endpoint soon, since the request syntax stays the same and a key costs nothing. Do not adopt it if you need a published rate ceiling, a tagged release to pin, or documented deployment steps, because none of those appear in this repository. Before committing, watch the status page for refresh cadence, read PW_OpenAPI.yaml against the endpoints you plan to call, and check LICENSE.md if you intend to redistribute anything.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Pirate-Weather/pirateweather on GitHub
4. README