Replace PyFilesystem2 with FS Next and drop the setuptools pin

[kmsk99]

Change

Replace fs with fs-next>=0.1.1,<0.2 and remove the setuptools<82 runtime dependency, then regenerate uv.lock. Existing import fs, MemoryFS and OSFS usage remains unchanged; no application code changes are needed. This offers a compatible migration option for #73 without rewriting filesystem calls.

I maintain FS Next, an independent maintenance fork rather than an official PyFilesystem release. It retains the fs import API and requires Python >=3.10, matching tilekiln's minimum. Its published-original regression suite and modern Python matrix are documented here: https://github.com/kmsk99/fs-next/blob/v0.1.1/docs/release-0.1.1.md . The 0.1.x upper bound keeps this proposal within the documented compatibility series.

Validation

• Original dependencies: 20 tests pass on macOS Python 3.14 (4 namespace/deprecation warnings).
• Fresh migrated environments: 20 tests pass on Python 3.10 and 3.14 without those warnings; pip/uv dependency checks pass.
• A disk-backed load_config with an external SQL template passes, with neither fs nor setuptools installed as distributions.
• TOML/YAML, conflict checks and Ruff hooks pass. Mypy with --platform linux passes all 25 source files.
• On macOS, both the original and migrated CLI hit the existing os.sched_getaffinity AttributeError; native-platform mypy reports the corresponding six errors. This PR does not claim to fix macOS CLI support. Live PostgreSQL/PostGIS integration has not been run locally; the existing storage unit tests use fake connections.

The lockfile also normalizes exceptiongroup's typing-extensions marker during uv regeneration; no unrelated package versions were upgraded. Users should create a fresh environment for the migration because fs and fs-next own overlapping module files.

This is a draft pending Linux CI verification and maintainer feedback. The fork did not create an Actions run for the branch push; Linux-targeted mypy above is not a Linux runtime test.

[pnorman]

Looks good to me.

One issue I had with pyfilesystem is that the jinja2 integration was very out of date and required an ancient jinja2 version. Is there anything suitable for fs-next?

If not, it's fine but influences my long-term planning.

[kmsk99]

Thanks for the review!

fs-next doesn't currently ship a Jinja2 loader. The latest jinja2-fsloader release still requires fs~=2.1 and jinja2~=2.0, and I haven't found a maintained packaged alternative supporting fs-next.

A small custom BaseLoader works with current Jinja2: I tested fs-next 0.1.1 with Jinja2 3.1.6, including {% include %} on MemoryFS.

I'd keep this PR focused on the dependency swap. If useful, I can prepare a separate PR adding include support to Tilekiln and addressing the TODO in definition.py.

[pnorman]

This PR looks good to me if you're ready to take it out of draft

[kmsk99]

Thanks, marked as ready for review.