[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) |
Hi,
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
lossy.
Ludo’.