guix-devel
[Top][All Lists]
Advanced

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

Re: Store channel specification in profile


From: zimoun
Subject: Re: Store channel specification in profile
Date: Wed, 4 Mar 2020 14:24:41 +0100

Hi Pierre,

On Wed, 4 Mar 2020 at 09:09, Pierre Neidhardt <address@hidden> wrote:
>
> zimoun <address@hidden> writes:
>
> >> I sorted the export so that it produces a reproducible output, which is
> >> more version-control friendly.
> >
> > IMHO, the sort would not be too expensive; even on all the packages
> > that Guix already includes now. ;-)
> > So, it does not matter too much, I guess.
>
> I think we are talking about different things :)

We are talking about the same thing. :-)
I am just saying that even if a profile is full of all the packages
that exists on Earth for Guix, then sorting will not be too
costly---if the 'sort' function in Guile is the state-of-art of
sorting, say merge-sort or quick-sort or tim-sort.


> What I meant is that if you keep the exported specs under version
> control, you will want the packages to be in the same order every time.

I agree.


> Other wise, you could very well have
>
> A
> B
> C
>
> then on next export
>
> A
> C
> B
>
> which is the same, but will warrant another commit in your repository
> (for no good reason).
> Ideally, we would like to avoid useless  commits.
>
> > However, the manifest returned is not necessary functional because the
> > pkg1@v1 and pkg2@v2 are not necessary provided by the same commit.
> > Therefore we could imagine "options" to the '--export' command, as
> > '--export=full' or '--export=light' etc. And even '--export=sorted'
> > and maybe combined as '--export=light,sorted'.
>
> As you mentioned in the other email, I think a more convenient solution
> to this is to use the format that I suggested which will include the
> provenance.

I do not remember exactly the format but I do remember our discussion
at the Guix Days.:-)
And I agree. :-)

> This will save the use from having to deal with too many CLI parameters.

Well, I was suggesting options for the CLI '--export' which was the
Ludo's suggestion.
These options are almost nothing to do once the exporter is done
(roughly your script sent elsewhere in this thread).
It is complementary to this very format, IMHO.


> Which I'm still against.  I find that including the specs within the
> profile is a much better idea: less effort, plus it ties the spec to a
> profile, thus giving a relationship guarantee to the user.

Well, I do not understand the '--export' suggestion as a replacement
of the format specification but I do understand it as an easy move
that improves the current situation. :-)

Cheers,
simon



reply via email to

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