-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pycdmsapi prototype #1
Comments
a) among the three options, I think approach one will give us more freedom and better long-term outcome. |
We could begin from scratch an create the new pycdmsapi application inspired by pygeoapi. Or we could:
Then we can begin to add our own modules that are CDMS specific, e.g. |
Starting with a copy of the pygeoapi code base would be ideal - because we would be starting with a working application. However, on reflection I don't think we can adopt the existing code en masse like this because the contributors to the pygeoapi project have not agreed to our project's Contributor's Licence Agreement (CLA). Therefore - I think the only way forward is approach (a): "create a completely separate package that follows the same principals and borrows some code". In this repository I've created a fresh package called pycdmsapi and registered this with PyPI. |
If we could create an example |
We can divide the task into two parts:
Converting pycdmsapi config to openapi specification depends largely on how would pycdmsapi config look like. To spin up a server from Open API specification we can take similar approach taken by openapi generator (https://openapi-generator.tech/docs/generators). It's done using mustache template. https://openapi-generator.tech/docs/generators Or we can take completely different approach, we can generate a fastapi app from pycdmsapi config file. Which automatically generates openapi spec. |
For the OpenCDMS Web API Reference Implementation, we would like to follow the framework-agnostic approach taken by pygeoapi which does not import dependencies from any particular Python web framework.
This first issue aims to investigate possible approaches. Should we:
a) create a completely separate package that follows the same principals and borrows some code
b) create a completely separate package that imports and reuses capabilities from pygeoapi where possible
c) maintain a fork of pygeoapi
d) ...
The text was updated successfully, but these errors were encountered: