[Top][All Lists]

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

Re: ~/.guix-profile/manifest usage with "guix package -m [manifest]" / "

From: Ludovic Courtès
Subject: Re: ~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc..
Date: Thu, 11 Oct 2018 15:44:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)


George Clemmer <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>> Hello,
>> Ricardo Wurmus <address@hidden> skribis:
> [...]
>>> You can put this in a file “manifest-to-manifest.scm” and run it like
>>> this from a Guix source checkout:
>>>     ./pre-inst-env guile -s manifest-to-manifest.scm /path/to/.guix-profile 
>>> > my-manifest.scm
>> I like how the script’s name highlights the naming inconsistency.  :-)
> ... and that we should consider renaming one of these "manifests" ;-)
>>> You can then proceed to install the generated manifest with:
>>>     guix package -m my-manifest.scm -p /path/to/new/.guix-profile
>>> If that’s what you’re looking for I suppose we could find a place for
>>> something like that under the umbrella of “guix package”.
>> The problem, as I see it, is that this might give a false impression
>> that both “manifests” are entirely equivalent, which is not the case.
> This "false impression" is caused by the "naming inconsistency" (above)
> rather that by the proposed function, isn't it?

True, the naming inconsistency is probably the root problem.  Now, it
should be said that ~/.guix-profile/manifest is not documented anywhere,
so people fiddling with it are on their own anyway.  :-)

>> I sympathize with George’s idea of making it easier to move from the
>> incremental style to the declarative style, but I wonder if we should go
>> beyond suggesting to basically copy the package names shown in “guix
>> package -I” to the manifest file.
> Does this mean to have "manifest-to-manifest.scm" add any non-default
> (in the current Guix version) package outputs and versions to the
> package specifications produced? Or something else?

manifest-to-manifest.scm works matching package names/versions, which
are ambiguous compared to store items.  This ambiguity means that the
“conversion” that manifest-to-manifest.scm performs is necessarily


reply via email to

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