feat: serialize pathlib paths like the other extra types

[shcheklein]

A model field declared as a Path cannot be stored:

class Doc(dc.DataModel):
    source: pathlib.PurePosixPath

class Batch(dc.DataModel):
    docs: list[Doc]

dc.read_values(b=[Batch(docs=[Doc(source=pathlib.PurePosixPath("/data/a.txt"))])]).save("b")
# TypeError: Object of type PurePosixPath is not JSON serializable

datachain.json exists to teach ujson the types it does not handle on its own — datetime, date, time, UUID, numpy arrays, bytes. Paths were missing, so a value that reaches the encoder still holding its Python type has nowhere to go.

That happens for a list of models, whose fields are dumped in Pydantic's python mode and therefore keep their Python types. The same model reached another way is converted by Pydantic first and stores fine, which is why this shows up in one shape and not another.

Paths are written with str(), which is what Pydantic's JSON mode produces for PurePath, PurePosixPath and Path alike, so a value written either way reads back identically. The test asserts that equivalence against model_dump(mode="json") rather than hard-coding a string.

Scope: values, not keys

Teaching the encoder about paths made one shape reachable that main rejected, and it stored badly — the key became its JSON text, quotes and all, the two read routes disagreed, and an equality filter matched nothing. So a path used as a mapping key is refused explicitly where _to_jsonable builds the mapping, keeping main's behaviour:

TypeError: Cannot use PurePosixPath as a mapping key: paths are not
supported as JSON object names

This covers a path key wherever _to_jsonable builds the mapping, which is every JSON column on both backends. It does not reach array items, whose handling already differs by backend for reasons unrelated to paths — that is untouched here.

Making rich mapping keys work — paths, datetimes, UUIDs — needs read-side reconstruction and filter normalisation, and none of them work today. That belongs with the read-path work in #1918.

Both encoder branches are covered: ujson silently coerces a path key while stdlib rejects it, so the tests assert path values work under serialize_bytes either way.

[cloudflare-workers-and-pages]

Deploying datachain with    Cloudflare Pages

Latest commit:	934e119
Status:	✅  Deploy successful!
Preview URL:	https://3d3b2bef.datachain-2g6.pages.dev
Branch Preview URL:	https://fix-json-encode-path.datachain-2g6.pages.dev

View logs

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[shcheklein]

Closing. Path was never the goal here — it entered as a regression of my own change.

The chain was: #1943's xfail needs live models to reach the converter as plain dicts, so I proposed flattening tuples like lists; that used python-mode model_dump(), which leaves a Path as a Path, which broke tuple[Model-with-Path, ...] — a shape that works on main because the warehouse converts it in JSON mode. This PR existed to stop that regression. That flatten change has since been dropped, so nothing depends on this.

It also does not earn its place on its own. Measured against main:

shape	main	this PR
Path as a direct field	ERR	ERR
list[Path]	ERR	ERR
dict[str, Path] (value)	ERR	saves, reads back a str
dict[Path, str] (key)	ERR	ERR
model w/ Path field	ERR	ERR
list[model w/ Path]	ERR	ok
tuple[model w/ Path,...]	ok	ok

One row fixed, one row turned from a loud failure into silent type loss. Not a good trade for three lines.

The useful finding is why: type support is spread across python_to_sql, the JSON encoder, the read converters, _convert_feature_value, and the key-encoding rules, each with its own list and no shared registry. list[model w/ Path] works only because pydantic rebuilds it from the model annotation; dict[str, Path] does not, because that reconstruction is DataChain's own and has never heard of Path. Same type, different layer, opposite result. Filing that separately.