~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc..

~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc..

[YOANN P]

Hi there,

I was thinking than "~/.guix-profile/manifest" was a valid manifest file due to his name, but it seems not that is the case from the error i've got

https://pastebin.com/Z7h2t5mL

After some search , i've finally understand that the instantiated profile couldn't be used as source profile for "guix package -m" etc... due to the same words despite use case and is a bit confusing

https://gnunet.org/bot/log/guix/2016-05-27#T1040380

It will be really convenient to only have the instantiate profile to easily maintain it in a vcs system.

Despite what ludo said in 2016 on IRC, i didn't see those options yet.
Did i missed them ?
If not implemented yet, any news about this feature ? :)

Thanks,

Best regards

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

[Ludovic Courtès]

Hello,

YOANN P <yoann_mac_donald@hotmail.com> skribis:

> I was thinking than "~/.guix-profile/manifest" was a valid manifest file due to his name, but it seems not that is the case from the error i've got
>
> https://pastebin.com/Z7h2t5mL
>
> After some search , i've finally understand that the instantiated profile couldn't be used as source profile for "guix package -m" etc... due to the same words despite use case and is a bit confusing

I agree it’s a bit confusing.  The manual does make it clear that -m
expects source code that evaluates to a manifest object, though.

> https://gnunet.org/bot/log/guix/2016-05-27#T1040380
>
> It will be really convenient to only have the instantiate profile to easily maintain it in a vcs system.
>
> Despite what ludo said in 2016 on IRC, i didn't see those options yet.
> Did i missed them ?
> If not implemented yet, any news about this feature ? :)

No news I’m afraid :-) but I’ve opened an issue so we keep track of it:

  https://issues.guix.info/issue/32844

Maybe you can help?

Thanks,
Ludo’.

RE: ~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc..

[YOANN P]

>De : Ludovic Courtès <ludo@gnu.org>
>Envoyé : mercredi 26 septembre 2018 10:19
>À : YOANN P
>Cc : guix-devel@gnu.org
>Objet : Re: ~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc..
> 
>Hello,

Hi,

>
>YOANN P <yoann_mac_donald@hotmail.com> skribis:
>
>> I was thinking than "~/.guix-profile/manifest" was a valid manifest file due to his name, but it seems not that is the case from the error i've got
>>
>> https://pastebin.com/Z7h2t5mL
>>
>> After some search , i've finally understand that the instantiated profile couldn't be used as source profile for "guix package -m" etc... due to the same words despite use case and is a bit confusing
>
>I agree it’s a bit confusing.  The manual does make it clear that -m
>expects source code that evaluates to a manifest object, though.
>

Indeed, but I only found the IRC discussion between alezost and you who explained it clearly.
I'm not sure that alezost and me was the only ones who do the same error, but maybe adding in manual a comparison between formats will be great, or maybe use another keyword for the instantiate manifest ?

>> https://gnunet.org/bot/log/guix/2016-05-27#T1040380
>>
>> It will be really convenient to only have the instantiate profile to easily maintain it in a vcs system.
>>
>> Despite what ludo said in 2016 on IRC, i didn't see those options yet.
>> Did i missed them ?
>> If not implemented yet, any news about this feature ? :)
>
>No news I’m afraid :-) but I’ve opened an issue so we keep track of it:
>
>  https://issues.guix.info/issue/32844
>
>Maybe you can help?
>

No offense, but, even if didn't try too many times to understand Guile Scheme, even if i really love Guix, the last time i tried to contribute (http://git.savannah.gnu.org/cgit/guix.git/commit/?id=6e0efe8cd5c85e7b83808b466c626484274def8d) I really was not comfortable with this new language and my brain found it hard to understand the indentation rules / closing parenthesis for a first approach.
If i acquire the skills to add it before someone doing it instead of me, i will submit it with pleasure, because i'm sure to be not the only one with this need :) and will be a pleasure to support a project i want  see growing.
 
>Thanks,
>Ludo’.

Nb: not directly related to this discussion, but since my last commit, i don't know if you already add it, but adding to your CI a build test for the packages with a custom store to be sure there is no hardcoded path to /gnu will prevent this kind of errors.

Thanks Ludo for always answering me, i really appreciate it.
Best regards,

Yoann

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

[Alex Kost]

(This message is unrelated to the bug)

YOANN P (2018-09-27 20:03 +0000) wrote:

[...]
> Indeed, but I only found the IRC discussion between alezost and you who explained it clearly.
> I'm not sure that alezost and me was the only ones who do the same
> error

For the records: I did not do any error, I always knew that a scheme
file for --manifest option and "~/.guix-profile/manifest" are different
things.  When I said "I think" I actually meant "I'm sure" (the latter
is a polite form of the former for me).

Sorry for bothering :-)

-- 
Alex

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

[Ludovic Courtès]

Hello,

YOANN P <yoann_mac_donald@hotmail.com> skribis:

> No offense, but, even if didn't try too many times to understand Guile Scheme, even if i really love Guix, the last time i tried to contribute (http://git.savannah.gnu.org/cgit/guix.git/commit/?id=6e0efe8cd5c85e7b83808b466c626484274def8d) I really was not comfortable with this new language and my brain found it hard to understand the indentation rules / closing parenthesis for a first approach.
> If i acquire the skills to add it before someone doing it instead of me, i will submit it with pleasure, because i'm sure to be not the only one with this need :) and will be a pleasure to support a project i want  see growing.

Sure, no problem.  :-)  We all rely heavily on editor support for
parenthesis matching and indentation.  The ‘etc/indent-code.el’ script
that comes with Guix helps with the latter (see
<https://www.gnu.org/software/guix/manual/en/html_node/Formatting-Code.html>).
Now I understand it takes some time to get used to it!

> Nb: not directly related to this discussion, but since my last commit, i don't know if you already add it, but adding to your CI a build test for the packages with a custom store to be sure there is no hardcoded path to /gnu will prevent this kind of errors.

No we don’t have such tests, but it’s a good idea.

Thanks,
Ludo’.

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

[George Clemmer]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> YOANN P <yoann_mac_donald@hotmail.com> skribis:
>
>> I was thinking than "~/.guix-profile/manifest" was a valid manifest file due to his name, but it seems not that is the case from the error i've got
>>
>> https://pastebin.com/Z7h2t5mL
>>
>> After some search , i've finally understand that the instantiated profile couldn't be used as source profile for "guix package -m" etc... due to the same words despite use case and is a bit confusing
>
> I agree it’s a bit confusing.  The manual does make it clear that -m
> expects source code that evaluates to a manifest object, though.
>
>> https://gnunet.org/bot/log/guix/2016-05-27#T1040380
>>
>> It will be really convenient to only have the instantiate profile to easily maintain it in a vcs system.
>>
>> Despite what ludo said in 2016 on IRC, i didn't see those options yet.
>> Did i missed them ?
>> If not implemented yet, any news about this feature ? :)
>
> No news I’m afraid :-) but I’ve opened an issue so we keep track of it:
>
>   https://issues.guix.info/issue/32844

Hi Ludo’,

Your bug doesn't capture some other manifest issues ...

"~/.guix-profile/manifest" and 'guix package --manifest=FILE' use the
same term/filename for markedly different things and the doc is silent
on the distinction. While "~/.guix-profile/manifest" may be internal to
Guix, users will inevitably trip across it and be confused (as YOANN did
here, and I did a year ago).

We might avoid confusion and make documentation easier by renaming one
of these. Consider ...

We are using "~/.guix-profile/manifest" in a way that is consistent with
a common use, e.g., shipping manifest, which specifies information not
in the associated order and at a level of detail that can only be
determined at shipment (e.g. serial number).

Our use of manifest in 'guix package --manifest=FILE' is rather less
intuitive. In fact this FILE is more like an order than a manifest,
IMO. As the doc says, [the manifest] 'FILE must return a “manifest”
object, which is roughly a list of packages'. If we were to rename this
a "package-list" or "package-spec", this would be more intuitive and
self-explanatory (at least to me, an English speaker), and make the doc
easier to write/understand.

YOANN hit an error when trying to do 'guix package -m
~/.guix-profile/manifest'. Why would one want to do this? Maybe to
(re)produce a configuration previously reached by a series of 'guix
package -i' operations?

In most situations, rather than a "~/.guix-profile/manifest" file, one
wants to use a 'guix package --manifest=FILE', since this is more
durable over time and easier to maintain (e.g. in SCC).

So, IMO, it would be useful to have something like ...

guix package --manifest-from-profile -p ~/.guix-profile > FILE

... which returns a "minimally specified" FILE that allows 'guix package
--manifest=FILE' to reproduce "~/.guix-profile".

- George

RE: ~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc..

[YOANN P]

>De : George Clemmer <myglc2@gmail.com>
>
>>Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello,
>>
>> YOANN P <yoann_mac_donald@hotmail.com> skribis:
>>
>>> I was thinking than "~/.guix-profile/manifest" was a valid manifest file due to his name, but it seems not that is the case from the error i've got
>>>
>>> https://pastebin.com/Z7h2t5mL
>>>
>>> After some search , i've finally understand that the instantiated profile couldn't be used as source profile for "guix package -m" etc... due to the same words despite use case and is a bit confusing
>>
>> I agree it’s a bit confusing.  The manual does make it clear that -m
>> expects source code that evaluates to a manifest object, though.
>>
>>> https://gnunet.org/bot/log/guix/2016-05-27#T1040380
>>>
>>> It will be really convenient to only have the instantiate profile to easily maintain it in a vcs system.
>>>
>>> Despite what ludo said in 2016 on IRC, i didn't see those options yet.
>>> Did i missed them ?
>>> If not implemented yet, any news about this feature ? :)
>>
>> No news I’m afraid :-) but I’ve opened an issue so we keep track of it:
>>
>>   https://issues.guix.info/issue/32844

Hi George,

>Hi Ludo’,
>
>Your bug doesn't capture some other manifest issues ...
>
>"~/.guix-profile/manifest" and 'guix package --manifest=FILE' use the
>same term/filename for markedly different things and the doc is silent
>on the distinction. While "~/.guix-profile/manifest" may be internal to
>Guix, users will inevitably trip across it and be confused (as YOANN did
>here, and I did a year ago).
>
>We might avoid confusion and make documentation easier by renaming one
>of these. Consider ...
>
>We are using "~/.guix-profile/manifest" in a way that is consistent with
>a common use, e.g., shipping manifest, which specifies information not
>in the associated order and at a level of detail that can only be
>determined at shipment (e.g. serial number).
>
>Our use of manifest in 'guix package --manifest=FILE' is rather less
>intuitive. In fact this FILE is more like an order than a manifest,
>IMO. As the doc says, [the manifest] 'FILE must return a “manifest”
>object, which is roughly a list of packages'. If we were to rename this
>a "package-list" or "package-spec", this would be more intuitive and
>self-explanatory (at least to me, an English speaker), and make the doc
>easier to write/understand.
>
>YOANN hit an error when trying to do 'guix package -m
>~/.guix-profile/manifest'. Why would one want to do this? Maybe to
>(re)produce a configuration previously reached by a series of 'guix
>package -i' operations?
>

Exactly that use case.
As said, i'm looking a way to have "a snapshot" of my profile to versioning it and be able to reproduce the exact same environnement associated if needed.
This way we could easily share the exact same environnement in dev, desktop case etc...

I don't know the utility of the instantiate manifest and the relations with it, but more precisly, this is how i had imaginated the instantiate manifest file at first and now how i would like to see / use it :

- Keep the informations who can only be determined at shipment
- All the informations necessary to build the environneent are there too and would override on the fly the .scm system definitions for the pakages list inside the profile. This way if the Guix system scm files was updated, guix would be always able to build the profile.

I don't know the implications of this feature, but Guix definilty need it if it didn't already exist :)

>In most situations, rather than a "~/.guix-profile/manifest" file, one
>wants to use a 'guix package --manifest=FILE', since this is more
>durable over time and easier to maintain (e.g. in SCC).
>

and please, even be able to read it from /dev/stdin.
it seems not available at now and is one of the last things i'm missing to be able to install a manifest through SSH.
My use case is to be able to install a profile on a rootless computer through SSH if needed.
I am today able to install some packages on a computer without root access and without guix installed in this way :

ssh guixpack@XXX.XXX.XXX.XXX -- '-R -S /opt/bin=/bin -S /etc=etc hello' | tar -xzf -

cloud_init.sh (debian stretch) : https://gist.github.com/rockandska/52d1a76b87e1e7bd6ce137c4ddab4b11

and what i would like to achieve is to be able to pipe a manifest from the rootless computer to the remote Guix server like this :

/tmp $ cat local_manifest | ssh guixpack@XXX.XXX.XXX.XXX -- '-R -m /dev/stdin -S /opt/bin=/bin -S /etc=etc hello' | tar -xzf -

Not sure about the security as is,not sure if it is the best way to do it too, but i had fun to test it and i would like to test it as an "anonymous" service for fun too ^^

>So, IMO, it would be useful to have something like ...
>
>guix package --manifest-from-profile -p ~/.guix-profile > FILE
>
>... which returns a "minimally specified" FILE that allows 'guix package
>--manifest=FILE' to reproduce "~/.guix-profile".
>
>- George

Yoann

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

[Ludovic Courtès]

Hello,

George Clemmer <myglc2@gmail.com> skribis:

> YOANN hit an error when trying to do 'guix package -m
> ~/.guix-profile/manifest'. Why would one want to do this? Maybe to
> (re)produce a configuration previously reached by a series of 'guix
> package -i' operations?

I agree this would be nice, but be aware that this is not quite possible
because those files don’t have enough information to rebuild packages.

Starting from a few weeks/months ago, ~/.guix-profile/manifest records
upstream VCS information, like this:

     ("libreoffice"
      "6.1.2.1"
      "out"
      "/gnu/store/y4l3r7nh0dg3d8qaifz96ffab4jpjl3s-libreoffice-6.1.2.1"
      (propagated-inputs ())
      (search-paths ())
      (properties
        (provenance
          (repository
            (version 0)
            (url "https://git.savannah.gnu.org/git/guix.git")
            (branch "master")
            (commit
              "f8e710684e5c3f866413dff825ba17bdffceac5d")))))

With this info and with inferiors and channels, it becomes possible to
rebuild the package (if we make simplifying assumptions.)

So I understand the need and agree that it would be nice.  But for now,
I strongly recommend “manifests as passed to ‘guix package -m’” because
they’re much more expressive, especially with the introduction of the
inferior API:

  https://issues.guix.info/issue/32759

HTH!

Ludo’.

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

[George Clemmer]

Hi Ludo’,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> George Clemmer <myglc2@gmail.com> skribis:
>
>> YOANN hit an error when trying to do 'guix package -m
>> ~/.guix-profile/manifest'. Why would one want to do this? Maybe to
>> (re)produce a configuration previously reached by a series of 'guix
>> package -i' operations?
>
> I agree this would be nice, but be aware that this is not quite possible
> because those files don’t have enough information to rebuild packages.
>
> Starting from a few weeks/months ago, ~/.guix-profile/manifest records
> upstream VCS information, like this:
>
>      ("libreoffice"
>       "6.1.2.1"
>       "out"
>       "/gnu/store/y4l3r7nh0dg3d8qaifz96ffab4jpjl3s-libreoffice-6.1.2.1"
>       (propagated-inputs ())
>       (search-paths ())
>       (properties
>         (provenance
>           (repository
>             (version 0)
>             (url "https://git.savannah.gnu.org/git/guix.git")
>             (branch "master")
>             (commit
>               "f8e710684e5c3f866413dff825ba17bdffceac5d")))))
>
> With this info and with inferiors and channels, it becomes possible to
> rebuild the package (if we make simplifying assumptions.)
>
> So I understand the need and agree that it would be nice.  But for now,
> I strongly recommend “manifests as passed to ‘guix package -m’” because
> they’re much more expressive, especially with the introduction of the
> inferior API:
>
>   https://issues.guix.info/issue/32759

IIUC, you are describing more-or-less "exact" (re)production of an
existing profile. But that's not what I was thinking of when I said
"(re)produce a configuration". Rather, I was thinking (as described
elsewhere in the original post) of the ability to produce “manifests as
passed to ‘guix package -m’” from an existing profile.

Why? In part to smooth over a puzzling inconsistency in guix
configuration: Systems configuration is "declarative" but user-profiles
may be "incremental" ('guix package -i') or "declarative" ('guix package
-m').

My thinking is that if there was an easy way to produce “manifests as
passed to ‘guix package -m’” from profiles, it would be a handy: an easy
way for someone that has gone down the incremental path to switch to
manifests and an easy way to update one's manifest after incremental
changes.

HTH - George

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

[Ricardo Wurmus]

Hi George,

> My thinking is that if there was an easy way to produce “manifests as
> passed to ‘guix package -m’” from profiles, it would be a handy: an easy
> way for someone that has gone down the incremental path to switch to
> manifests and an easy way to update one's manifest after incremental
> changes.

Do you mean something like this?

--8<---------------cut here---------------start------------->8---
(use-modules (guix profiles)
             (ice-9 match)
             (ice-9 pretty-print))

(match (command-line)
  ((_ where)
   (pretty-print
    `(specifications->manifest
      ',(map manifest-entry-name (manifest-entries (profile-manifest where))))))
  (_ (error "Please provide the path to a Guix profile.")))
--8<---------------cut here---------------end--------------->8---

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

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”.

-- 
Ricardo

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

[George Clemmer]

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi George,
>
>> My thinking is that if there was an easy way to produce “manifests as
>> passed to ‘guix package -m’” from profiles, it would be a handy: an easy
>> way for someone that has gone down the incremental path to switch to
>> manifests and an easy way to update one's manifest after incremental
>> changes.
>
> Do you mean something like this?
>
> --8<---------------cut here---------------start------------->8---
> (use-modules (guix profiles)
>              (ice-9 match)
>              (ice-9 pretty-print))
>
> (match (command-line)
>   ((_ where)
>    (pretty-print
>     `(specifications->manifest
>       ',(map manifest-entry-name (manifest-entries (profile-manifest where))))))
>   (_ (error "Please provide the path to a Guix profile.")))
> --8<---------------cut here---------------end--------------->8---
>
> 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
>
> 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”.

Hi Ricardo,

Nice! Yes, this is the idea and it worked here for me, thank you.

Ideally this would recover additional package specification details when
needed. E.g., I did 'guix package -i guile@2.2:debug' but only "guile"
was added to my-manifest.scm.

TIA! - George

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

[Ludovic Courtès]

Hello,

Ricardo Wurmus <rekado@elephly.net> skribis:

>> My thinking is that if there was an easy way to produce “manifests as
>> passed to ‘guix package -m’” from profiles, it would be a handy: an easy
>> way for someone that has gone down the incremental path to switch to
>> manifests and an easy way to update one's manifest after incremental
>> changes.
>
> Do you mean something like this?
>
> (use-modules (guix profiles)
>              (ice-9 match)
>              (ice-9 pretty-print))
>
> (match (command-line)
>   ((_ where)
>    (pretty-print
>     `(specifications->manifest
>       ',(map manifest-entry-name (manifest-entries (profile-manifest where))))))
>   (_ (error "Please provide the path to a Guix profile.")))
>
> 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.  :-)

> 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.

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.

Thoughts?

Ludo’.

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

[George Clemmer]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Ricardo Wurmus <rekado@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?

> 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?

- George

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

[Ludovic Courtès]

Hi,

George Clemmer <myglc2@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello,
>>
>> Ricardo Wurmus <rekado@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’.