-
-
Notifications
You must be signed in to change notification settings - Fork 290
Description
Is your feature request related to a problem? Please describe.
Some of the pygeoapi configuration properties are not really related to pygeoapi itself, but to the underlying web application server (e.g. gunicorn, uvicorn, etc.). I mean these:
server.bind
server.gzip
server.cors
Additionally, the whole logging
configuration section is also not related to pygeoapi itself but to whatever web application framework (e.g. flask, starlette, etc.) is wrapping pygeoapi.
When integrating with a third-party web application framework and web server I want to use their respective means of providing these configuration parameters.
I also don't want to have to provide these in the pygeoapi configuration, as it can become confusing to have them in there and can also complicate initialization of things.
Describe the solution you'd like
I'm proposing the removal of these configuration properties from the pygeoapi configuration.
What to do about the default pygeoapi flask/starlette/django applications that are run when calling pygeoapi serve
then?
I propose that we implement some sane defaults and let the user modify them via environment variables and CLI options if needed.
For example, we would use localhost:5000
as the default bind address and port but would allow the pygeoapi flask/starlette/django wrapper applications (and not pygeoapi core) to probe the process environment for the existence of PYGEOAPI_[FLASK, STARLETTE, DJANGO]_BIND_HOST
and PYGEOAPI_[FLASK, STARLETTE, DJANGO]_BIND_PORT
variables which could override the defaults. We would also provide --bind-host
and --bind-port
parameters to the pygeoapi serve
CLI command.
Describe alternatives you've considered
A possible alternative is to at least make all of the aforementioned configuration properties optional so that their absence does not trigger a failure of the config validation.
Activity