Hi!

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
>> The Plan©:
>>
>> On every profile installation, we generate a "specifications.scm" file alongside
>> the internal "manifest".
>
> One thing to keep in mind, though, is that if the ‘specifications.scm’
> is part of the profile, it must be future-proof.  That is, the APIs it
> uses must essentially be guaranteed to remain forever.  That’s a very
> strong constraint.

I think that's OK.  In the example format I suggested, we use keys, which
make it easy to extend the format later on, if need be.

> In contrast, versioned data formats like the famous ‘manifest’ file
> don’t have this problem at all, but they’re less directly usable from
> the CLI.

We can version the specifications.scm as well.  Can you explain what the
problem is, I think I'm missing the point.

>> Proposed format for "specifications.scm": we can reuse
>> `specifications->manifest`.  Each entry is either or string, in which case it
>> acts as before, or a list, with the following self-explanatory elements:
>>
>> (specifications->manifest
>>  '(("my-package"
>>     #:outputs '("out")
>>     #:version "2.3"
>>     #:channel (channel
>>                (name 'guix)
>>                (branch "master")
>>                (url "https://git.savannah.gnu.org/git/guix.git")
>>                (commit
>>                 "704719edade1368f798c9301f3a8197a0df5c930")))
>>    ("my-package2")
>>    "old-style-package"))
>
> As a rule of thumb, I think ‘specifications->manifest’ must remain what
> it is: it should take a specification as is currently defined and return
> a manifest.  I think that if we need a new concept, we should not
> overload an existing one.

In my understanding it's not so much of a new concept as an extension of
the existing one.  But defining a new function is not a problem at all
either.

What about

  specifications->manifest*

?

> We also need to distinguish between APIs, which should use first-class
> objects (<channel>, etc.), and data formats, which are plain sexps.
> (The above example is a mixture of both and in fact looks very similar
> to what’s already in the ‘manifest’ file.)  But then again, that means
> relying on a larger chunk of the API.

I'm not sure I understood what you meant here.  Which APIs?

> So, all in all, I think I’d rather see it implemented as ‘guix package
> --export’ or similar.

I think I didn't understand why you'd prefer to have a command instead
of systematically generating the file inside the profile.  Or maybe we
could generate the file somewhere else if that's the problem?

In my opinion, the `--export` approach would be cumbersome because it
means that for users who want to save the specifications file, they'd
need to systematically call it on every profile-modifying command, e.g.

  guix package -m manifest.scm && guix package --export

> There could also be an option to generate a “symbolic” manifest: one
> that would install packages of the same name, but not resorting to
> inferiors.

I think this can be implemented with the --use-default-channels option I
suggested before.

> As far as faithfulness is concerned, we should also keep in mind that we
> don’t always have all the information needed to reconstruct what’s in a
> profile.  For example, we lack information about the package
> transformation options that were used (if any),

Like `--with-input'?
I didn't think of this.  Can't we extend the format then to include all
transformation options, with future-proof provisions?

Example:

--8<---------------cut here---------------start------------->8---
(specifications->manifest
 '(("my-package"
    #:outputs '("out")
    #:version "2.3"
    #:transformation '((input PACKAGE REPLACEMENT)
                       (source SOURCE))
    #:channel (channel
               (name 'guix)
               (branch "master")
               (url "https://git.savannah.gnu.org/git/guix.git")
               (commit
                "704719edade1368f798c9301f3a8197a0df5c930")))
--8<---------------cut here---------------end--------------->8---

> and we lack information about arbitrary user code that might have been
> used to generate manifest entries.

Is this a problem?  Even if we only store generated manifest entries,
this should be enough to reproduce the profile, no?

-- 
Pierre Neidhardt
https://ambrevar.xyz/