Repository navigation
Add missing Python SDK endpoints - #61
nik-solcast wants to merge 2 commits into
Conversation
Add TMY Advanced PV, utility-scale measurements, schedules, and Premium Wind site resource methods. Update SDK docs and tests, add JSON-body support to PATCH and PUT, and pin Black in CI.
There was a problem hiding this comment.
🟢 Approval recommended
The endpoint additions, transport changes, tests, and documentation have no identified blocking issues.
No open issues 🎉
What changed in this PR
Extends the Python SDK with missing resource and data endpoints using the existing client.
Changes:
- Adds Advanced PV TMY, utility measurement uploads, schedules, and Premium Wind resource methods.
- Supports JSON bodies for PATCH and PUT and removes default format parameters from measurement deletes.
- Adds tests and documentation and pins Black in CI.
| File | Description |
|---|---|
| tests/test_wind_power_sites.py | Tests Wind resource requests. |
| tests/test_site_measurements.py | Updates DELETE query expectations. |
| tests/test_forecast_docs.py | Checks forecast method documentation and links. |
| tests/test_advanced_site_and_schedule_endpoints.py | Tests new endpoints and JSON requests. |
| solcast/wind_power_sites.py | Adds Wind resource management methods. |
| solcast/wind_power_site_measurements.py | Removes default DELETE format parameters. |
| solcast/urls.py | Adds endpoint paths. |
| solcast/tmy.py | Adds Advanced PV TMY retrieval. |
| solcast/schedules.py | Adds schedule retrieval and management. |
| solcast/pv_power_sites.py | Adds measurement-array uploads. |
| solcast/pv_power_site_measurements.py | Removes default DELETE format parameters. |
| solcast/api.py | Adds PATCH and PUT JSON-body support. |
| solcast/__init__.py | Exports new modules. |
| mkdocs.yml | Adds documentation navigation entries. |
| docs/wind_power_sites.md | Documents Wind resource management. |
| docs/tmy.md | Documents Advanced PV TMY retrieval. |
| docs/schedules.md | Documents schedule operations. |
| docs/pv_power_sites.md | Documents utility measurement uploads. |
| docs/forecast.md | Lists existing soiling forecast methods. |
| .github/workflows/black.yml | Pins Python and Black versions. |
Review effort: Balanced
| | Method | Purpose | | ||
| |---|---| | ||
| | `create_pv_site_measurements` | Submit site measurements. | | ||
| | `create_utility_scale_site_measurements` | Submit measured power data for an Advanced PV site. | |
There was a problem hiding this comment.
I think this name will lead to confusion. It could be taken to mean that the other measurements are not utility scale, whereas in fact they are. That utility-scale endpoint is mainly used for the super_rapid product.
This is a bit of a mess now, because we have to clearly express what is different between create_utility_scale_pv_site_measurements and create_pv_site_measurements, with it not being clear that the latter is for premium.
Also, I think it is unfortunate that we have ended up with repetitive naming, with the same information in the module name and the function name. Compare with forecasts where it is forecast.premium_pv_power, not forecast.premium_pv_power_forecast. I should have picked up on that with previous reviews.
Analogous with that would be
measurement.create_premium_pv
measurement.create_premium_wind
measurement.create_standard_pv <- could be what we call non-premium usage?
measurement.create_premium_pv_sub_site
etc.
That would be a major breaking change. If we are doing that, I think we should more fully plan it out before we proceed. E.g. when we introduce premium aggregations, do their forecasts go under the aggregations module or the forecasts module?
Summary
Verification