Re: Store channel specification in profile

[Ludovic Courtès]

Howdy!

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!

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