refactor: Refactor pyrorisks

[jsakv]

The PR introduces the following changes:

• refactor:

  • Remove Heroku deployment files; the service is no longer used by Pyronear
  • Remove CML / DVC pipelines; will revisit mlops tooling later if necessary
  • Deprecate the outdated pyro_risks modules, CLI, and examples

• chore:

  • Add poetry for packaging and dependency management
  • Add ruff for linting and formatting
  • Update docker build and config
  • Update CI workflows
  • Bump Geopandas to 1.0.1, replace fiona backend with pyogrio with speedups >5-20x

• style: Fix type hints, formatting, and linting

• docs: Remove deprecated modules from docs

To speed up the API deployment, the refactored version of the repository only targets Linux distributions and python 3.10; multi-platform and multi-version builds will come later. It will also allow us to assess if a mix of poetry and conda is required for installation across platforms (cf pyrovision, pyroengine).

I plan on adding unit test workflow with the next PR!

Any feedback is welcomed 🌲

[Acruve15]

[QUESTION] should we name it app or api?

[jsakv]

Both can work. I named it app to match the top-level directory and the fast API app/API convention, but api is straightforward!

[juldpnt]

[QUESTION] Why use both ruff and black ? Ruff can be a direct replacement for black, so it seems it is redundant

[jsakv]

True, thanks for catching that!

[juldpnt]

Thank you for this PR !! I have a little question, I'm wondering if you chose Python 3.10 for technical reasons/compatibility? The 3.11 (or even 3.12) would give many QOLs for typing, interpreter errors, etc.

[jsakv]

Thank you for this PR !! I have a little question, I'm wondering if you chose Python 3.10 for technical reasons/compatibility? The 3.11 (or even 3.12) would give many QOLs for typing, interpreter errors, etc.

Fair question; the main concern was to avoid incompatibilities and reduce the surface for build errors.
For instance, geopandas supports Python 3.9+, rasterio has 3.12 wheels but is not being tested (CI) on Python 3.12, and pyogrio has had compatibility issues with Python 3.12 recently.

These few points are enough to rule out Python 3.12 preventively IMHO, and on the other sidePython 3.9 is approaching its end of life in ~ one year.

The package is compatible with Python 3.10 and 3.11, but I went with the 3.10 version for the docker image and the CI. The idea is to introduce relevant multi-platform and multi-version builds later!