’guix package --export-manifest’ using ’@version’?

’guix package --export-manifest’ using ’@version’?

[zimoun]

Hi,

I have not noticed at the time when discussing ’export-manifest’.  Sorry
to have overlooked that.


Because of #:entry-package-version,

--8<---------------cut here---------------start------------->8---
  (match (manifest->code manifest
                         #:entry-package-version
                         manifest-entry-version-prefix)
--8<---------------cut here---------------end--------------->8---

the output of the option ’export-manifest’ is not stateless; as it was
initially commented in 9fd7b050e2198c89f0763fe79f5c541b77b8e5c9 and then
refactored elsewhere (package-unique-version-prefix).

--8<---------------cut here---------------start------------->8---
+        (versions
+         ;; If ENTRY uses the latest version, don't specify any version.
+         ;; Otherwise return the shortest unique version prefix.  Note that
+         ;; this is based on the currently available packages, which could
+         ;; differ from the packages available in the revision that was used
--8<---------------cut here---------------end--------------->8---

For instance, it reads,

--8<---------------cut here---------------start------------->8---
$ guix time-machine --commit=fb32a38db1d3a6d9bc970e14df5be95e59a8ab02 \
       -- package -p gnu/store/vmn2b3cmfwf250i65rgvkamyr4971q7m-profile
         --export-manifest

;; This "manifest" file can be passed to 'guix package -m' to reproduce
;; the content of your profile.  This is "symbolic": it only specifies
;; package names.  To reproduce the exact same profile, you also need to
;; capture the channels being used, as returned by "guix describe".
;; See the "Replicating Guix" section in the manual.

(specifications->manifest
(list "python" "python-numpy"))
--8<---------------cut here---------------end--------------->8---

or it reads,

--8<---------------cut here---------------start------------->8---
$ guix package -p gnu/store/vmn2b3cmfwf250i65rgvkamyr4971q7m-profile \
       --export-manifest
;; This "manifest" file can be passed to 'guix package -m' to reproduce
;; the content of your profile.  This is "symbolic": it only specifies
;; package names.  To reproduce the exact same profile, you also need to
;; capture the channels being used, as returned by "guix describe".
;; See the "Replicating Guix" section in the manual.

(specifications->manifest
(list "python@3.8" "python-numpy@1.17"))
--8<---------------cut here---------------end--------------->8---


I think it is confusing and maybe a wrong pattern.

Many people are already confused by the fact that the package versions
are fixed by the Guix revision and there is no “version solver”; as it
is the case for all the other package managers.

Being able to provide a version in the manifest (or from the CLI) is a
marginal case – when Guix provides several versions of the same
package, it is few cases when the vast majority of the packages have
only one version for one revision.

Somehow, this information about version is redundant (and useless) with
the revision.  The only useful information for capturing the versions is
the revision.

If one has this manifest.scm file with the version specified,
considering that one runs “guix shell -m manifest.scm”, then one would
probably get «error: python: package not found for version 3.8», for
instance.

Moreover, if the profile – created long time ago – contains many more
than 2 packages, then this exported manifest requires many removal of
versions (at least) to be usable with a new revision.


The export of the versions depending on the state appears to me
confusing; for newcomers or people from the classical package managers.
And it provides more work when transitioning from imperative to
declarative.


Therefore, I think ’--export-manifest’ should not report the version and
it should be stateless.  However, we could add a comment about
“--export-channels”.

WDYT?


Cheers,
simon

Re: ’guix package --export-manifest’ using ’@version’?

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> $ guix package -p gnu/store/vmn2b3cmfwf250i65rgvkamyr4971q7m-profile \
>        --export-manifest
> ;; This "manifest" file can be passed to 'guix package -m' to reproduce
> ;; the content of your profile.  This is "symbolic": it only specifies
> ;; package names.  To reproduce the exact same profile, you also need to
> ;; capture the channels being used, as returned by "guix describe".
> ;; See the "Replicating Guix" section in the manual.
>
> (specifications->manifest
> (list "python@3.8" "python-numpy@1.17"))

[...]

> The export of the versions depending on the state appears to me
> confusing; for newcomers or people from the classical package managers.
> And it provides more work when transitioning from imperative to
> declarative.
>
>
> Therefore, I think ’--export-manifest’ should not report the version and
> it should be stateless.  However, we could add a comment about
> “--export-channels”.

(Nitpick: it *is* stateless, in the sense that it only depends on Guix
itself, not on the state of the machine where it is being run.)

I see what you mean, but I disagree with the conclusion.

‘--export-manifest’ emits a comment (shown above) explaining that the
manifest is symbolic and that one needs channel info to replicate the
exact same environment.

It is a departure from traditional package managers, and admittedly
surprising to newcomers.  However, my take on this is that we should be
very upfront about symbolic vs. exact reproducibility.  We would muddy
the waters if we gave version strings the same importance as in other
tools, when we know that a version string means very little.

Thoughts?

Ludo’.

Re: ’guix package --export-manifest’ using ’@version’?

[zimoun]

Hi,

On Thu, 07 Jul 2022 at 09:57, Ludovic Courtès <ludo@gnu.org> wrote:

> (Nitpick: it *is* stateless, in the sense that it only depends on Guix
> itself, not on the state of the machine where it is being run.)

I will not argue about what we call state here. :-)


> ‘--export-manifest’ emits a comment (shown above) explaining that the
> manifest is symbolic and that one needs channel info to replicate the
> exact same environment.

I do not understand what you mean by «symbolic» here.


> It is a departure from traditional package managers, and admittedly
> surprising to newcomers.  However, my take on this is that we should be
> very upfront about symbolic vs. exact reproducibility.  We would muddy
> the waters if we gave version strings the same importance as in other
> tools, when we know that a version string means very little.

I miss about what you disagree because «We would muddy the waters if we
gave version strings the same importance as in other tools, when we know
that a version string means very little.» is the exact root of my
comment.

By returning,

        (specifications->manifest
        (list "python" "python-numpy"))

or

        (specifications->manifest
        (list "python@3.8" "python-numpy@1.17"))

depending on the current Guix is just doing that: «muddy the waters».


Instead, I think ’--export-manifest’ should *always* return:

        (specifications->manifest
        (list "python" "python-numpy"))

without ’@x.y.z’.  Other said, be in agreement with the comment:

;;                               This is "symbolic": it only specifies
;; package names.  To reproduce the exact same profile, you also need to
;; capture the channels being used, as returned by "guix describe".

and not sometimes ’package name’ and sometimes ’package name + version’;
as if version string has a special meaning.


To be honest, I do not understand: on one hand, we are advocating that
version string is not enough for reproducibility.  On the other hand, we
output version string with a comment «version string is useless, you
need a channel file for replicating».


Since I am missing a point, could you explain more?


Cheers,
simon

Re: ’guix package --export-manifest’ using ’@version’?

[Ludovic Courtès]

zimoun <zimon.toutoune@gmail.com> skribis:

> On Thu, 07 Jul 2022 at 09:57, Ludovic Courtès <ludo@gnu.org> wrote:

[...]

>> It is a departure from traditional package managers, and admittedly
>> surprising to newcomers.  However, my take on this is that we should be
>> very upfront about symbolic vs. exact reproducibility.  We would muddy
>> the waters if we gave version strings the same importance as in other
>> tools, when we know that a version string means very little.
>
> I miss about what you disagree because «We would muddy the waters if we
> gave version strings the same importance as in other tools, when we know
> that a version string means very little.» is the exact root of my
> comment.
>
> By returning,
>
>         (specifications->manifest
>         (list "python" "python-numpy"))
>
> or
>
>         (specifications->manifest
>         (list "python@3.8" "python-numpy@1.17"))
>
> depending on the current Guix is just doing that: «muddy the waters».
>
> Instead, I think ’--export-manifest’ should *always* return:
>
>         (specifications->manifest
>         (list "python" "python-numpy"))
>
> without ’@x.y.z’.  Other said, be in agreement with the comment:

Oh sorry, I had misunderstood your comment.

The “@X.Y” bit is added only when necessary to disambiguate the package
spec.  So with today’s Guix, we have:

--8<---------------cut here---------------start------------->8---
$ guix shell guile --export-manifest
;; What follows is a "manifest" equivalent to the command line you gave.
;; You can store it in a file that you may then pass to any 'guix' command
;; that accepts a '--manifest' (or '-m') option.

(specifications->manifest (list "guile"))
$ guix shell guile@2.2 --export-manifest
guix shell: warning: ambiguous package specification `guile@2.2'
guix shell: warning: choosing guile@2.2.7 from gnu/packages/guile.scm:250:2
guix shell: warning: ambiguous package specification `guile@2.2'
guix shell: warning: choosing guile@2.2.7 from gnu/packages/guile.scm:250:2
;; What follows is a "manifest" equivalent to the command line you gave.
;; You can store it in a file that you may then pass to any 'guix' command
;; that accepts a '--manifest' (or '-m') option.

(specifications->manifest (list "guile@2.2.7"))
$ guix shell guile@2.0 --export-manifest
;; What follows is a "manifest" equivalent to the command line you gave.
;; You can store it in a file that you may then pass to any 'guix' command
;; that accepts a '--manifest' (or '-m') option.

(specifications->manifest (list "guile@2.0"))
--8<---------------cut here---------------end--------------->8---

In these cases, we cannot omit the “@X.Y” bit because the manifest would
then designate something different.

Does that make sense?

Ludo’.

Re: ’guix package --export-manifest’ using ’@version’?

[zimoun]

Hi,

On Thu, 07 Jul 2022 at 17:13, Ludovic Courtès <ludo@gnu.org> wrote:

> The “@X.Y” bit is added only when necessary to disambiguate the package
> spec.  So with today’s Guix, we have:

Yes, but it is not what I reported initially [1]; it was:

1: https://yhetil.org/guix/868rp8zosc.fsf@gmail.com

--8<---------------cut here---------------start------------->8---
$ guix time-machine --commit=fb32a38db1d3a6d9bc970e14df5be95e59a8ab02 \
       -- package -p gnu/store/vmn2b3cmfwf250i65rgvkamyr4971q7m-profile
       --export-manifest

;; This "manifest" file can be passed to 'guix package -m' to reproduce
;; the content of your profile.  This is "symbolic": it only specifies
;; package names.  To reproduce the exact same profile, you also need to
;; capture the channels being used, as returned by "guix describe".
;; See the "Replicating Guix" section in the manual.

(specifications->manifest
(list "python" "python-numpy"))
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
$ guix package -p gnu/store/vmn2b3cmfwf250i65rgvkamyr4971q7m-profile \
       --export-manifest
;; This "manifest" file can be passed to 'guix package -m' to reproduce
;; the content of your profile.  This is "symbolic": it only specifies
;; package names.  To reproduce the exact same profile, you also need to
;; capture the channels being used, as returned by "guix describe".
;; See the "Replicating Guix" section in the manual.

(specifications->manifest
(list "python@3.8" "python-numpy@1.17"))
--8<---------------cut here---------------end--------------->8---


However, I am not able to reproduce; because I removed this profile – it
comes from my attempt to reproduce Docker pack.  Other said, note that
the profile is not in /gnu/store/ but extracted from a Docker pack built
with --save-provenance.

Trying other examples, I am not able to see it again.  Hum?!


Sorry for the noise if it is a bug between the keyboard and the chair. ;-)


> In these cases, we cannot omit the “@X.Y” bit because the manifest would
> then designate something different.

I agree.


Sorry for the noise.  The current behaviour is the one we agree and is
expected.  I thought that I have observed another.  Hum?!

Well, time for me to take summer holidays? :-)


Cheers,
simon