Add gravel-fragility

[rhoekstr]

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the licenses of these are packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

About the package

gravel-fragility is a C++20 library with Python bindings for road network fragility analysis — computing how isolated a location (or region) becomes when some fraction of its roads fail. Target users: transportation researchers, GIS analysts, disaster-resilience planners.

• Upstream: https://github.com/rhoekstr/gravel
• PyPI: https://pypi.org/p/gravel-fragility (v2.2.1 shipped today)
• Docs: https://rhoekstr.github.io/gravel/
• License: Apache-2.0

Why conda-forge

The conda-forge build additionally enables OSM loaders (load_osm_graph, OSMConfig, SpeedProfile) via the conda-forge libosmium package. PyPI wheels ship with OSM disabled because libosmium isn't distributed on PyPI — so for users who want to load OpenStreetMap road networks (the primary use case), conda-forge is the proper channel.

Recipe notes

• Uses a single patch (01-pybind11-find-package.patch) to swap pybind11 from FetchContent to find_package (required for the network-blocked conda-forge build sandbox). All other C++ deps in upstream (nlohmann_json, Catch2, Eigen3, Spectra) already have FIND_PACKAGE_ARGS in their FetchContent_Declare calls, so they resolve to the conda-forge host deps directly.
• GRAVEL_USE_OSMIUM=ON is set via pip install ... -C cmake.define.GRAVEL_USE_OSMIUM=ON.
• Minimum Python 3.10.
• Tested locally: recipe passes conda-smithy recipe-lint.

I am the upstream maintainer

I am @rhoekstr, the author of gravel. Happy to be pinged for future version-bump PRs.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/gravel-fragility/meta.yaml) and found it was in an excellent condition.

[rhoekstr]

Bumped recipe to v2.2.2 — released to PyPI earlier today. Release notes: https://github.com/rhoekstr/gravel/releases/tag/v2.2.2

Key change in v2.2.2 (relevant to this recipe): OSM loaders are now enabled in every PyPI wheel, which was previously the headline reason to prefer conda-forge over PyPI. The conda-forge build still has value for environments that want conda-managed C++ dependencies and stdlib ABI pinning — plus conda-forge maintains its own libosmium which means OSM support was never build-time network-gated there anyway.

Recipe diff from the v2.2.1 version: version bump + fresh sha256 for the v2.2.2 tarball. cmake/Dependencies.cmake is unchanged between the two releases, so the 01-pybind11-find-package.patch continues to apply cleanly without regeneration. Still linter-clean per conda-smithy recipe-lint.