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
