Hi, George Clemmer <myg...@gmail.com> skribis:
> Ludovic Courtès <l...@gnu.org> writes: > >> Hello, >> >> Ricardo Wurmus <rek...@elephly.net> 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’.
