nlohmann::json instance and JSON Schema for MemorySourceAccessor
#14319
Conversation
src/json-schema-checks/meson.build
Outdated
| '--map', | ||
| './hash-v1.yaml=' + schema_dir / 'hash-v1.yaml', |
roberth
left a comment
roberth
left a comment
There was a problem hiding this comment.
This seemed so simple, but bytes strike again.
| ../../src/libutil-tests/data/memory-source-accessor | ||
| ../../src/libutil-tests/data/hash |
There was a problem hiding this comment.
Maybe these should point the other way around?
Being a documentation example is more significant than being tested as part of some test suite.
Also it's helpful for the test suite to have an explicit reference to path that's in the manual, to distinguish it from test cases that only exist for the purpose of testing, i.e. corner cases that aren't relevant enough for the manual.
There was a problem hiding this comment.
I switched it from your version because of how _NIX_TEST_ACCEPT works, especially when making new files.
There was a problem hiding this comment.
Can it not write through a symlink? IIRC I had something like tests/data/examples point into the manual. Wouldn't it just write to data/examples/new-file if you passed examples/new-file as the stem?
Otherwise, I guess we could use a naming convention to highlight which examples are for docs.
| contents: | ||
| type: object | ||
| description: | | ||
| Map of names to nested file system objects (for type=directory) |
There was a problem hiding this comment.
There's probably semantics we want to document here, like we don't allow /?
Probably best to make a link, so that we don't duplicate all prose here.
I guess we could encode a no / restriction with draft 6 propertyNames if we want.
There was a problem hiding this comment.
Names may not be valid UTF-8 and therefore not be valid JSON (sequence of unicode characters, https://www.rfc-editor.org/rfc/rfc8259#section-1)
One possible solution, if this is something we've tested that it even works:
"It is commonly accepted that file names should be UTF-8, but not guaranteed.
Nix will forward invalid names, so if you wish to support all possible NARs in your application, you will need to use a parser that forwards invalid UTF-8 into your application, and allows you to produce invalid UTF-8 in the JSON you may have to output."
Alternatively, we could require base 64 here too.
Same applies to the symlink targets.
There was a problem hiding this comment.
Or we could have a LenientString type that's either a valid JSON string, or a { "base64": ... }, but that only helps for values, not field names. I guess we could steal syntax and have "/aGVsbG8=": be an equivalent, non-canonical field name to "hello":.
So LenientString would be a type for representing values that are typically valid strings, but may not always be, and base 64 would be an unwarranted hindrance in practice. (Not sure about the latter; maybe we should just use it for file contents too?)
| const: "symlink" | ||
| target: | ||
| type: string | ||
| description: Target path of the symlink. |
There was a problem hiding this comment.
Another lack of semantics. Should probably just be a link.
What is the meaning of an absolute path? Or a relative path? Can a relative path be allowed to ..-leave the FSO? I don't think the manual has good answers yet, but this should link to what we have, @docroot@/store/file-system-object.md
Ericson2314
force-pushed
the
json-schema-fso
branch
from
9afb7e5 to
4d3d4b5
Compare
Ericson2314
force-pushed
the
json-schema-fso
branch
4 times, most recently
from
31bebf4 to
a1c39ed
Compare
github-actions
bot
added
the
with-tests
Ericson2314
force-pushed
the
json-schema-fso
branch
from
a1c39ed to
d6be2bc
Compare
…the CLI Make instances for them that share code with `nix path-info`, but do a slightly different format without store paths containing store dirs (matching the other latest JSON formats). Progress on NixOS#13570. If we depend on the store dir, our JSON serializers/deserializers take extra arguements, and that interfaces with the likes of various frameworks for associating these with types (e.g. nlohmann in C++, Serde in Rust, and Aeson in Haskell). For now, `nix path-info` still uses the previous format, with store dirs. We may yet decide to "rip of the band-aid", and just switch it over, but that is left as a future PR.
As documented, this for file system objects themselves, since `MemorySourceAccessor` is an implementation detail.
Ericson2314
force-pushed
the
json-schema-fso
branch
from
d6be2bc to
dfbb101
Compare
2 participants
Motivation
As documented, this for file system objects themselves, since
MemorySourceAccessoris an implementation detail.Context
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.