Re: Using --manfistest with /manifest files

[elaexuotee]

This is a good point. The naming of `/manifest' does invite confusion
when first encountering it.

That said, I am pretty sure there is a place for `/manifest.scm'.
Given the `--manifest' option to several commands, it makes profiles first
class. In particular, it would let users easily `guix pack' or `guix archive'
arbitrary profiles as needed. At the moment, it's not at all obvious how to
`guix pack' the equivalent of `guix environment --container '.

FWIW, I never expected `/manifest' to encode "this is what the user
ordered," so much as "this is the recipe for (deterministically) reproducing
this exact profile." For the former we have `packages->manifest',
`specifications->manifest' etc. The latter is what I understand this discussion
to be about.

George Clemmer  wrote:
> 
> Ludovic Courtès  writes:
> 
> > elaexuo...@wilsonb.com skribis:
> 
> >> First, am I missing something? Is there a better/preferred way to make use 
> >> of
> >> the `manifest' files in profiles?
> 
> > You’re not missing anything: it’s a longstanding source of confusion
> > that these ‘manifest’ files are not like the ‘manifest.scm’ files.
> > These ‘manifest’ files are meant for internal consumption.
> 
> This hurt my head for a while a few years ago until I realized that
> 'manifest.scm' is the guix "order" and ‘.guix-profile/manifest’ is the
> guix "packing list".
> 
> But actually a guix' 'manifest' packing list goes well beyond what we
> normally find in a packing list by containing detailed info about how
> the specific products were made, down to the specific design for the
> specific version shipped.
> 
> Thought of this way it is easy to understand why a receiver of a
> 'manifest' can only estimate the set of 'manifest.scm' that might
> produce it. A simple-minded example: did the manifest.scm specify the
> version of the package shipped or is this an artifact of a) when
> 'manifest.scm' was processed or b) of the requirements of the other
> packages that were received?
> 
> In any event, once I saw it this way it no longer troubled me that guix
> doesn't have a pushbutton way to "reverse" 'manifest' into
> 'manifest.scm'.
> 
> ISTM we set ourselves up for confused users and a lot of explaining by
> labeling two very different things with same name :-0
> 
> Yes, only 'manifest.scm' is in the doc, but '.guix-profile/manifest'
> smacks a user in the face pretty quickly which leads to these messy
> questions.
> 
> IMO we could dramatically simplify the situation, and simplify our
> lives, by simply renaming the .guix-profile/manifest file ;-)
> 
> George




signature.asc
Description: PGP signature

Re: Using --manfistest with /manifest files

[George Clemmer]

Ludovic Courtès  writes:

> elaexuo...@wilsonb.com skribis:

>> First, am I missing something? Is there a better/preferred way to make use of
>> the `manifest' files in profiles?

> You’re not missing anything: it’s a longstanding source of confusion
> that these ‘manifest’ files are not like the ‘manifest.scm’ files.
> These ‘manifest’ files are meant for internal consumption.

This hurt my head for a while a few years ago until I realized that
'manifest.scm' is the guix "order" and ‘.guix-profile/manifest’ is the
guix "packing list".

But actually a guix' 'manifest' packing list goes well beyond what we
normally find in a packing list by containing detailed info about how
the specific products were made, down to the specific design for the
specific version shipped.

Thought of this way it is easy to understand why a receiver of a
'manifest' can only estimate the set of 'manifest.scm' that might
produce it. A simple-minded example: did the manifest.scm specify the
version of the package shipped or is this an artifact of a) when
'manifest.scm' was processed or b) of the requirements of the other
packages that were received?

In any event, once I saw it this way it no longer troubled me that guix
doesn't have a pushbutton way to "reverse" 'manifest' into
'manifest.scm'.

ISTM we set ourselves up for confused users and a lot of explaining by
labeling two very different things with same name :-0

Yes, only 'manifest.scm' is in the doc, but '.guix-profile/manifest'
smacks a user in the face pretty quickly which leads to these messy
questions.

IMO we could dramatically simplify the situation, and simplify our
lives, by simply renaming the .guix-profile/manifest file ;-)

George

Re: Helping with powerpc64-linux

[lle-bout]

On 6/14/20 4:41 AM, Chris Marusich wrote:
> Hi Léo,
> 
> As you know, I'm still investigating why the powerpc64-linux bootstrap
> binaries (really just GCC) are not reproducible [1].  Eventually, if we
> can't figure it out, we might want to just bite the bullet and use the
> non-reproducible bootstrap binaries to get started, but I'm hopeful we
> can figure it out and have at least two different people build the same
> binaries before doing that.
> 
> The investigation is slow, partially because building things without
> substitutes is very slow (iteration time is in hours or days).  In the
> meantime, I understand you've been continuing to work on building more
> powerpc64-linux packages on top of your own bootstrap binaries [2].  I
> also understand you've had some trouble setting up Cuirass on your
> POWER9 PC.  I'd like to help (and invite others to help, if they want),
> but I'm not sure what the current status is.
> 
> Is Cuirass still not working?  I checked your POWER9 Gentoo VM, and I
> saw that Cuirass is not currently running.
> 
> Which branches in your Git repository are still relevant?  My
> understanding is that only the following branches in your repo might
> currently contain changes we would want to upstream into Guix:
> 
>   - master: the first attempts you made.
>   - wip-lle-bout-be1: your more recent attempts.
> 
> Do you think we should we try adding powerpc64le-linux?  Since the
> powerpc64-linux bootstrap binaries are not reproducible, I see no reason
> to expect that the powerpc64le-linux binaries would be reproducible,
> either, but you never know.  Maybe it's worth a try.
> 
> Is there something else I can help you with?  I will have time while
> waiting for long builds to finish, but please forgive me if my progress
> is slow.  Life is busy.  Slowly but surely, we can make progress, and
> hopefully we can keep collaborating to make it happen!
> 
> Footnotes: 
> [1]  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669
> 
> [2]  https://gitlab.com/lle-bout/guix
> 

Hello!

I'm busy as well with many things that werent planned at all! (Not a
job, but matters I need to contribute to **now** because it will be
impossible later)

The most recent changes are uncommitted and inside the VM in /root/guix
- but if they werent committed it means things are in flux.

Things to fix would be Go bootstrapping, using gccgo instead of go@1.4
as specified in the comment, because go@1.4 doesnt support ppc64[le],
lots of tools are in go. And you could investigate creating bootable ISO
inspiring yourself from how Debian does it for ppc64el.

Cuirass still isnt working, I havent had time to continue since my last
messages.

To get the state I was at, you need to (as root):

# cd /root/cuirass-data
# cuirass -D cuirass.sqlite -S specfile.scm --web --cache-directory=cache &
# cuirass -D cuirass.sqlite -S specfile.scm --cache-directory=cache

The reason is that you can't get both the web interface and the
background service that runs builds at the same time, so you need to run
it twice.

After that, you can access through http://localhost:8080 (from the
machine itself, so make an SSH tunnel).

I ran it on the machine inside a screen session.

For powerpc64le, I installed an Ubuntu ppc64el VM using nested KVM in
/root/ubuntu-ppc64le.qcow2

You can run it with (as root):

# cd /root
# qemu-system-ppc64 -drive format=qcow2,file=ubuntu-ppc64le.qcow2
-device virtio-net,netdev=vmnic -netdev user,id=vmnic -enable-kvm -m 8G
-smp 16,sockets=16,cores=1,threads=1 -nodefaults -nographic -serial
stdio -machine cap-ccf-assist=off

This will give you a little endian VM from within the big endian VM with
minimal performance overhead.

I gave gentoo-ppc64 access to efraim as well, so they worked a little on
it as well. I initially investigated the nested KVM for them, but it's
done now.

We can also try little endian, but bootstrap-tarballs don't even build
right now, let alone reproducibility. I'll try to help as soon as I can
for investigating lack of reproducibility of these GCC binaries. I have
a beefier x86 server than you for this AFAICT, but I'm not sure I could
give access.

I hope to resume work again on GNU Guix soon!

Thanks a lot,
Leo




signature.asc
Description: OpenPGP digital signature

Re: Blog post on Further reduced bootstrap seed to 25%

[Maxim Cournoyer]

Hello Jan,

Jan Nieuwenhuizen  writes:

> Hello Guix!
>
> I’ve published a post about the second big reduction of the Guix
> bootstrap binaries
>
> https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
>
> Thanks to the recent merge of ‘core-updates’ some weeks days ago, the
> set of bootstrap binaries now weighs in at approximately 60 MiB; about
> 25% of what it used to be.
>
> Thanks to Timothy Samplet, Danny Milosavljevic and Ludovic Courtès for
> their feedback and help on an earlier version of this post!
>
> Greetings,
> Janneke

Thank you for this very well written blog post!  It's a fantastic
achievement that benefits us all Guix users.

Congratulations!

Maxim

Re: Blog post on Further reduced bootstrap seed to 25%

[Danny Milosavljevic]

Hi Janneke,

On Mon, 15 Jun 2020 14:54:39 +0200
Jan Nieuwenhuizen  wrote:

> I’ve published a post about the second big reduction of the Guix
> bootstrap binaries
> 
> https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/

"again decided to sponsor this work" link is broken

Otherwise good :)


pgpF6DS0rJec8.pgp
Description: OpenPGP digital signature

Re: [PATCH] sql: Add a couple of indexes.

[Christopher Baines]

zimoun  writes:

> Hi Chris,
>
> On Sun, 14 Jun 2020 at 12:48, Christopher Baines  wrote:
>
>>> --8<---cut here---start->8---
>>>   65.7% substitutes available (9,425 out of 14,354)
>>>   at least 57,816.3 MiB of nars (compressed)
>>>   97,343.9 MiB on disk (uncompressed)
>>>   0.010 seconds per request (138.1 seconds in total)
>>>   103.0 requests per second
>>>
>>>   0.0% (0 out of 4,929) of the missing items are queued
>>>   at least 1,000 queued builds
>>>   x86_64-linux: 1000 (100.0%)
>>>   build rate: 9.20 builds per hour
>>>   x86_64-linux: 9.20 builds per hour
>>> --8<---cut here---end--->8---
>>>
>>> Hum?  Almost 1/3 of substitutes are not available and in the same time
>>> not queued.  Is it expected?  Does it mean that 1/3 of the builds are
>>> failing?
>>
>> Probably not, most likely canceled or a dependency failed to build.
>
> Well, it depends on how you define what is a build. ;-) Because if one
> package's dependency does not build, the package cannot build either.

Yeah. Given this is about Cuirass, I was sort of using the Cuirass build
states, which does distinguish a build that was attempted, and failed,
from one which couldn't be attempted because an input was lacking.


signature.asc
Description: PGP signature

Latest download from website

[Mathieu Othacehe]

Hello,

Here's a wip patch for the website. It adds a new "download/latest"
page allowing to download the latest Guix System images from Cuirass.

I've merged all the required mechanisms in Guix and Cuirass, now most of
the remaining work is "cosmetic" (and that's not my cup of tea).

Anyway, the patch and a screenshot are attached, please tell me what you
think.

Thanks,

Mathieu
>From 1ef4c571934118deaae93f7f6eccc23ed8c32f9a Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe 
Date: Mon, 15 Jun 2020 17:13:25 +0200
Subject: [PATCH] wip: website: Add "latest" downloads.

---
 website/apps/base/templates/components.scm|  12 +-
 website/apps/download/builder.scm |   6 +-
 .../download/templates/download-latest.scm| 159 ++
 website/static/base/css/common.css|   5 +
 4 files changed, 180 insertions(+), 2 deletions(-)
 create mode 100644 website/apps/download/templates/download-latest.scm

diff --git a/website/apps/base/templates/components.scm b/website/apps/base/templates/components.scm
index a10fb00..3252dc7 100644
--- a/website/apps/base/templates/components.scm
+++ b/website/apps/base/templates/components.scm
@@ -290,7 +290,17 @@
  (h2 (@ (class "a11y-offset")) "Website menu:")
  (ul
   ,(menu-item #:label "Overview" #:active-item active-item #:url (guix-url))
-  ,(menu-item #:label "Download" #:active-item active-item #:url (guix-url "download/"))
+
+  ,(menu-dropdown #:label "Download"
+  #:active-item active-item
+  #:items
+  (list
+   (menu-item #:label "Stable"
+  #:active-item active-item
+  #:url (guix-url "download/"))
+   (menu-item #:label "Latest"
+  #:active-item active-item
+  #:url (guix-url "download/latest/"
   ,(menu-item #:label "Packages" #:active-item active-item #:url (guix-url "packages/"))
   ,(menu-item #:label "Blog" #:active-item active-item #:url (guix-url "blog/"))
 
diff --git a/website/apps/download/builder.scm b/website/apps/download/builder.scm
index 0b6..cc983c5 100644
--- a/website/apps/download/builder.scm
+++ b/website/apps/download/builder.scm
@@ -4,6 +4,7 @@
 
 (define-module (apps download builder)
   #:use-module (apps download templates download)
+  #:use-module (apps download templates download-latest)
   #:use-module (apps download data)
   #:use-module (haunt html)
   #:use-module (haunt page)
@@ -30,13 +31,16 @@
RETURN (list of )
  A list of page objects that represent the web resources of the
  application. See Haunt  objects for more information."
-  (list (download-builder)))
+  (list (download-builder)
+(download-latest-builder)))
 
 
 
 ;;;
 ;;; Helper builders.
 ;;;
+(define (download-latest-builder)
+  (make-page "download/latest/index.html" (download-latest-t) sxml->html))
 
 (define (download-builder)
   "Return a Haunt page representing the Download page of the website."
diff --git a/website/apps/download/templates/download-latest.scm b/website/apps/download/templates/download-latest.scm
new file mode 100644
index 000..c14db8e
--- /dev/null
+++ b/website/apps/download/templates/download-latest.scm
@@ -0,0 +1,159 @@
+;;; GNU Guix web site
+;;; Initially written by sirgazil who waives all
+;;; copyright interest on this file.
+;;;
+;;; This file is part of the GNU Guix web site.
+;;;
+;;; The GNU Guix web site is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU Affero General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; The GNU Guix web site is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU Affero General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU Affero General Public License
+;;; along with the GNU Guix web site.  If not, see .
+
+(define-module (apps download templates download-latest)
+  #:use-module (apps base templates theme)
+  #:use-module (apps base types)
+  #:use-module (apps base utils)
+  #:use-module (apps download templates components)
+  #:use-module (guix ci)
+  #:use-module (srfi srfi-1)
+  #:use-module (srfi srfi-9)
+  #:use-module (ice-9 match)
+  #:export (download-latest-t))
+
+(define ci-url "https://ci.guix.gnu.org;)
+
+(define-record-type 
+  (make-image description logo job type)
+  image?
+  (description image-description)   ;string
+  (logoimage-logo)  ;string
+  (job image-job)   ;string
+  (typeimage-type)) ;string
+
+(define images
+  (list (make-image
+ "GNU Guix System ISO-9660 

Blog post on Further reduced bootstrap seed to 25%

[Jan Nieuwenhuizen]

Hello Guix!

I’ve published a post about the second big reduction of the Guix
bootstrap binaries

https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/

Thanks to the recent merge of ‘core-updates’ some weeks days ago, the
set of bootstrap binaries now weighs in at approximately 60 MiB; about
25% of what it used to be.

Thanks to Timothy Samplet, Danny Milosavljevic and Ludovic Courtès for
their feedback and help on an earlier version of this post!

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Using --manfistest with /manifest files

[elaexuotee]

zimoun,

In response to your previous email, I gave a long-form reply to the general
discussion. However, I just want to note that the personal issue I am
encountering isn't with user profiles; instead it is with those generated by
`guix environment'.

In particular, I was trying to use `guix pack' to share the *development*
environment of a package with a non-guix user. As I shared in my original
email, the (imperfect) solution I used was by wrapping `/manifest'
with `read-manifest' and feeding that to `guix pack --manifest':

(call-with-input-file "/manifest"
  (@@ (guix packages) read-manifest)

zimoun  wrote:
> Hi,
> 
> On Sun, 14 Jun 2020 at 17:24, Ludovic Courtès  wrote:
> 
> > I think there were several issues we discussed:
> >
> >   1. We can only approximate that actual profile content; storing
> >  an approximate ‘manifest.scm’ along with the profile would IMO be
> >  deceptive.
> >
> >   2. It’s easy to maintain compatibility over a data format, but it’s
> >  much harder to maintain compatibility for code.
> >
> > I think we discussed these issues the best we could in the megathread,
> > so I’m personally in favor of moving forward in a pragmatic way.
> 
> By pragmatic way, you mean:
> 
>  - let the format of /manifest as it is,
>  - write '--export-manifest' as an approximation
> 
> right?
> 
> Well, I personally changed my workflow and now I always use manifest
> files.  And the situation that I described in the manifest about the
> "Working Scientific" doing install, pull, install, pull, remove,
> install, etc. is rooted in bad practises, so it should be avoided.
> 
> Therefore, I agree that '--export-manifest' is the right approach, as an
> helping tool; too bad for some corner cases. :-)
> 
> 
> All the best,
> simon




signature.asc
Description: PGP signature

Re: Using --manfistest with /manifest files

[elaexuotee]

> It is more "complicated" than that.  The detailed explanations are in
> the mega thread. :-) In short and from my understanding, going from
> "/manifest" to "-m manifest.scm" cannot be done in the general
> case because two concepts -- imperative vs declarative -- are not well
> aligned.  Pragmatically, it means that the result could be more than
> often unpractical with too much inferiors.  Well, only an
> "approximation" could be exported.

I went ahead and read through the threads that Pierre shared in a different
reply. For posterity and to collect my own thoughts, let me see if I can
distill the discussion so far:


The goal is to enable a profile to generate itself by reifying it into some
collection of code and data. Given such a tool, two places of use are proposed:

1) Implicitly, upon profile generation, outputting new files under /etc, or
2) Explicitly via a command like `guix package --export'.

It turns out that `guix system reconfigure' does some (most?) of this by
generating `/gnu/store/-provenance' and `/gnu/store/-channels.scm'
along with the profile itself.

Naively, a profile is just a sum of outputs; however, there are subtleties:

a) Provenance and inferiors
   For reproducibility, channel and revision information must be stored.

This is alreading in profile/manifest, however, so we already have the
necessary infrastracture in this regard.

b) The family of `--with-*' options to `guix package' means that provenance
   data itself is insufficient. Worse, `--expression' means that the collection
   of outputs might be specified with *arbitrary code*.

That said, the sum of provenance and command-line invocation should be
sufficient, no? If so, an extreme proof-of-concept reification could simply be
a bash script, something akin to the following:

#!/bin/env bash
guix time-machine -C /channels.scm -- \
guix package -p  [ ...]

c) Profile reifications need to be forward-compatible, meaning that future
   revisions of guix should produce the same profile as current/older ones
   given a reification.

This, of course, shows why the bash script idea is untenable, but with a more
reasonable Guile implementation, storing version information in the way of
`/manifest' neatly solves this issue.


Am I missing any major points? Almost surely there are minor ones I am
overlooking. Here are some of my questions:

Theorem: Given provenance data (e.g. a `channels.scm' file) and a command line
 invocation, profiles generation is deterministic.

Note that by "command line invocation" I am including any external files its
options reference as well.

Is this true at least mostly? Ludo mentions something about the "possibility of
multiple provenances" which I fail to grok. What is going on here? Does this
introduce a source of non-determinism for users building profiles? I.e. given
the right bash script, can a user reliably reproduce a given profile?

If the answer to the final question above is no, then that seems like a much
larger problem. However, if the answer is yes, then I would naively expect
profile reification to be mostly a matter of collecting together all the
sources of input that define a profile. Does forward-compatibility make this
less straightforward than I am thinking? What else am I missing?

> Sorry I am too lazy to search, but I think I remember that at the time
> Pierre sent -- probably in the mega thread :-) -- a small script to
> extract relevant information from /manifest; the preliminary
> for '--export-manifest'. :-)

Perhaps you are thinking of Pierre's script here?
https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00154.html


Cheers,


signature.asc
Description: PGP signature

Re: [PATCH] sql: Add a couple of indexes.

[zimoun]

Hi Chris,

On Sun, 14 Jun 2020 at 12:48, Christopher Baines  wrote:

>> --8<---cut here---start->8---
>>   65.7% substitutes available (9,425 out of 14,354)
>>   at least 57,816.3 MiB of nars (compressed)
>>   97,343.9 MiB on disk (uncompressed)
>>   0.010 seconds per request (138.1 seconds in total)
>>   103.0 requests per second
>>
>>   0.0% (0 out of 4,929) of the missing items are queued
>>   at least 1,000 queued builds
>>   x86_64-linux: 1000 (100.0%)
>>   build rate: 9.20 builds per hour
>>   x86_64-linux: 9.20 builds per hour
>> --8<---cut here---end--->8---
>>
>> Hum?  Almost 1/3 of substitutes are not available and in the same time
>> not queued.  Is it expected?  Does it mean that 1/3 of the builds are
>> failing?
>
> Probably not, most likely canceled or a dependency failed to build.

Well, it depends on how you define what is a build. ;-) Because if one
package's dependency does not build, the package cannot build either.

I agree that these 1/3 non-available substitutes can be because only one
essential package fails.  We discussed at Guix Days something like "guix
weather --release"; which could help to report what maintainers/developers
consider as essential.

However, I feel that something is lacking to identify which package is
failing and what is its impact.  Something like: the build fails then a
warning is raised if "guix refresh -l" is too high.


Cheers,
simon

Re: Using --manfistest with /manifest files

[zimoun]

Hi,

On Sun, 14 Jun 2020 at 17:24, Ludovic Courtès  wrote:

> I think there were several issues we discussed:
>
>   1. We can only approximate that actual profile content; storing
>  an approximate ‘manifest.scm’ along with the profile would IMO be
>  deceptive.
>
>   2. It’s easy to maintain compatibility over a data format, but it’s
>  much harder to maintain compatibility for code.
>
> I think we discussed these issues the best we could in the megathread,
> so I’m personally in favor of moving forward in a pragmatic way.

By pragmatic way, you mean:

 - let the format of /manifest as it is,
 - write '--export-manifest' as an approximation

right?

Well, I personally changed my workflow and now I always use manifest
files.  And the situation that I described in the manifest about the
"Working Scientific" doing install, pull, install, pull, remove,
install, etc. is rooted in bad practises, so it should be avoided.

Therefore, I agree that '--export-manifest' is the right approach, as an
helping tool; too bad for some corner cases. :-)


All the best,
simon

Re: Using --manfistest with /manifest files

[zimoun]

Dear,

On Thu, 11 Jun 2020 at 10:40, elaexuo...@wilsonb.com wrote:
> In an attempt to tar up the *build* environment for a package to share with a
> colleague, I encountered this:
>
> [env]$ guix pack -m $GUIX_ENVIRONMENT/manifest
> (manifest ...): Wrong number of arguments
>
> From playing around a bit, my guess is that the `/manifest' files are
> just human-readable serializations of  objects and don't deserialize
> back:
>
> $ guix environment -m ~/.guix-profile/manifest
> (manifest ...): Wrong number of arguments

It is more "complicated" than that.  The detailed explanations are in
the mega thread. :-) In short and from my understanding, going from
"/manifest" to "-m manifest.scm" cannot be done in the general
case because two concepts -- imperative vs declarative -- are not well
aligned.  Pragmatically, it means that the result could be more than
often unpractical with too much inferiors.  Well, only an
"approximation" could be exported.

Sorry I am too lazy to search, but I think I remember that at the time
Pierre sent -- probably in the mega thread :-) -- a small script to
extract relevant information from /manifest; the preliminary
for '--export-manifest'. :-)

Otherwise, let open /manifest, write an Emacs macro and extract
the relevant information. ;-)


Well, because I hit the same problem some time ago -- well when I raised
or revived the discussion about this conversion -- I fixed for myself by
converting by hand some profiles and totally changed my workflow.

Now, I never use "guix install" but always "guix package -m".  For
temporary test, I extend the profile with "guix environment" which is on
purpose because it is a temporary profile; if it is worth, I add the
package to the manifest file.

(Sometimes, I run "guix install foo -p /tmp/foo" to test something
temporary, mainly when I try to figure out an issue that has been
reported.)

Each time, I run "guix package -m" or "guix update", then I run in the
same time "guix describe" and track the output.

Well, I have 2 kind of manifests:

 - the ones of my setup, living under ~/.config/guix/manifests and where
   I applied some recipe of [1]
 - the ones of projects I work on, living in the project folder

and each manifest is accompanied by channel.scm (guix describe -f).  And
I have almost no package in ~/.guix-profile but they live separated
profiles (Emacs, Python, Apps, etc.).


All the best,
simon


1:
https://guix.gnu.org/cookbook/en/html_node/Guix-Profiles-in-Practice.html#Guix-Profiles-in-Practice

Re: Using --manfistest with /manifest files

[Pierre Neidhardt]

Hi,

Ludovic Courtès  writes:

> I think there were several issues we discussed:

Allow me to reiterate, at the risk of bikeshedding... :)

>   1. We can only approximate that actual profile content; storing
>  an approximate ‘manifest.scm’ along with the profile would IMO be
>  deceptive.

Why is an approximate file more of a problem than a command producing
an approximate result?  We could include a warning comment at the top of
the file to make it explicit that it's approximate.

>   2. It’s easy to maintain compatibility over a data format, but it’s
>  much harder to maintain compatibility for code.

I'm confused: my suggestion is to add a new data format, so isn't it
better then?

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature