Howdy! Pierre Neidhardt <m...@ambrevar.xyz> skribis:
> Ludovic Courtès <l...@gnu.org> writes: [...] >> I would, however, use sexps as a serialization format. Compared to an >> API, an object serialized to an sexp has the advantage that we can write >> code to handle changes in the serialization format, so it’s future-proof >> if we get it right. But then: we’re back to ‘manifest’. :-) >> >> I hope this is a bit clearer, but I realize it’s tricky to discuss such >> things! > > Indeed, because we were on the same page all along: my "keyed code snippet" > was about the serialization format, not the data structure! Good. >> ‘manifest’ looks like this: >> >> (manifest >> (version 3) >> …) >> >> We have an explicit ‘read-manifest’ procedure that can handle version 3, >> but also prior versions, and this is all transparent. >> >> You cannot do that with code. Code is just evaluated, and if it’s >> incompatible, if fails in some unspecified way. > > Same thing, what I had in mind was to store the version number in the > _serialized_ specifications.scm, as for the manifest. > > This way I believe we can support multiple version for specifications.scm. > Am I missing something? Then I don’t get how ‘specifications.scm’ would differ from ‘manifest’. In both cases we’re talking about a serialization format containing per-package provenance info, right? >> We could store package transformations as manifest entry properties. >> >> However, that’ll be an approximation: the exact implementation of >> ‘--with-input’, for instance, can vary over time. > > Hmmm, even if we have the provenance? Yes. >> After all, the goal of the functionality we’re discussing is to allow >> users to move towards the declarative ‘manifest.scm’ style, right? > > Yes, so I'll try to sum up what I want to achieve in one sentence: > "automate the textual serialization of profile specifications to > simplify their backup/deployment/reproduction". OK. To me, serialization is already automated: it’s the ‘manifest’ file. What we lack is the ability to obtain a “manifest.scm” kind of file (code) that users can pick as a starting point in their migration towards declarative deployment. Does that make sense? Am I paraphrasing you correctly? :-) Thanks, Ludo’.
