From: Pierre Neidhardt <mail@ambrevar.xyz>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Store channel specification in profile
Date: Thu, 06 Feb 2020 11:59:10 +0100 [thread overview]
Message-ID: <87eev8gewx.fsf@ambrevar.xyz> (raw)
In-Reply-To: <87wo91p9yt.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 4505 bytes --]
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/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
next prev parent reply other threads:[~2020-02-06 10:59 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-26 14:55 Store channel specification in profile Pierre Neidhardt
2019-11-26 16:40 ` Konrad Hinsen
2019-11-26 19:12 ` Pierre Neidhardt
2019-11-26 19:35 ` Konrad Hinsen
2019-12-02 15:58 ` zimoun
2019-12-09 17:11 ` Ludovic Courtès
2019-12-09 17:21 ` Pierre Neidhardt
2019-12-12 19:50 ` zimoun
2019-12-12 22:35 ` Pierre Neidhardt
2019-12-13 12:16 ` zimoun
2019-12-19 16:12 ` Ludovic Courtès
2019-12-19 17:18 ` zimoun
2020-01-06 20:07 ` Pierre Neidhardt
2020-01-06 21:09 ` zimoun
2020-01-08 15:17 ` Pierre Neidhardt
2020-01-08 19:31 ` zimoun
2020-01-11 23:48 ` Ludovic Courtès
2020-01-13 14:02 ` Pierre Neidhardt
2020-01-13 14:46 ` zimoun
2020-01-13 14:37 ` zimoun
2020-01-13 14:59 ` Pierre Neidhardt
2020-01-13 15:53 ` zimoun
2020-01-13 16:53 ` Pierre Neidhardt
2020-01-30 19:24 ` Pierre Neidhardt
2020-01-31 8:51 ` zimoun
2020-01-31 9:21 ` Konrad Hinsen
2020-01-31 11:21 ` Pierre Neidhardt
2020-01-31 12:15 ` Pierre Neidhardt
2020-01-31 16:01 ` Konrad Hinsen
2020-02-05 11:08 ` Ludovic Courtès
2020-02-06 10:59 ` Pierre Neidhardt [this message]
2020-02-07 21:28 ` Ludovic Courtès
2020-02-08 17:09 ` Pierre Neidhardt
2020-02-11 14:10 ` Ludovic Courtès
2020-02-11 14:18 ` Pierre Neidhardt
2020-02-24 16:16 ` Ludovic Courtès
2020-02-25 10:32 ` Pierre Neidhardt
2020-03-03 21:43 ` zimoun
2020-03-04 8:09 ` Pierre Neidhardt
2020-03-04 13:24 ` zimoun
2020-03-03 21:49 ` zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eev8gewx.fsf@ambrevar.xyz \
--to=mail@ambrevar.xyz \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.