[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Store channel specification in profile

From: Ludovic Courtès
Subject: Re: Store channel specification in profile
Date: Tue, 11 Feb 2020 15:10:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)


Pierre Neidhardt <address@hidden> skribis:

> Ludovic Courtès <address@hidden> 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!


>> ‘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?


>> 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".


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?  :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]