create titiler namespaces packages

[vincentsarago]

ref: #278

Why

As mentioned in #278, TiTiler is much more than an application, it's a python module that lets user create custom Tiler.

I believe that splitting core and application could help users to have a better understanding but also help us to move quickly on some features.

How

• titiler.core: core functions (e.g tiler factories)

Tiler factories, ressources and models

• titiler.application: demo application

basic application (adds Uvicorn, python-dotenv and brotli dependencies)

main changes

• split core functionalities and demo application
• move custom (colormap, tms) to the demo application
• removed unused function titiler.utils.get_hash
• switch to pkg_resources to locate templates files

other

• use a bash script instead of tox to do PyPI publishing

To Do

• talk
• update docs
• update readmes

[vincentsarago]

I moved all custom code to the application part

[vincentsarago]

moved the linters config to setup.cfg

[vincentsarago]

Uvicorn is optional (e.g when running the application in AWS Lambda you don't need Uvicorn)

[vincentsarago]

this function wasn't used in titiler

[vincentsarago]

because titiler-application depends on titiler-core, we install them manually

[vincentsarago]

Still awaiting for feedback but if we move forward with namespaces here is IMO what we could do:

• move mosaic features into titiler.mosaic (done in 33c59a1)
• add rio-tiler-mvt feature (https://github.com/developmentseed/titiler-mvt) into titiler.raster_to_vector

Maybe

• titiler.mvt instead of https://github.com/developmentseed/timvt
• titiler.public_datasets instead of https://github.com/developmentseed/titiler-pds
• titiler.stac_api (WIP) a mosaic backend based on stac_fastapi
• titiler.aiocogeo based on aiocogeo

cc @geospatial-jeff @kylebarron

[kylebarron]

Quick notes from chat

• Decide whether to use - or . in PyPI names, i.e. pip install titiler.core or pip install titiler-core. (AWS CDK uses ., Google uses -, I use .)
• Should follow up on whether you can use mypy in pre-commit still after moving to namespaces. In my experience, any linters/code formatters that are purely static are a good fit for pre-commit (black, isort, yapf, pylint, etc). If the tool needs to follow imports (mypy, pytest), then it's simplest to run in each module individually.
• Ideally put all config in config files, e.g. mypy.ini, setup.cfg, pyproject.toml (my preferred, since it's a PEP standard). Then whether run inside or outside pre-commit should give the same output.