Best practice when dealing with a broken package for guix home?

Best practice when dealing with a broken package for guix home?

[Fredrik Salomonsson]

Hi,

Using guix home to manage my home environment is awesome.  But one thing
I haven't figured out is a good way of handling when one package is
broken.  As that effectively blocks any upgrade until that it is fixed.

There are generally three things I do in that case:

1) Temporarily remove it from my configuration if I don't use that
program that often.

2) Use `options->transformation` to pick a commit/branch etc that
compiles.

3) Copy an older definition that works to my custom channel, add a
prefix and use that until it is fixed.

If an issue isn't reported I usually send in a bug report with a patch
based on 2 or 3.  But most often someone else have reported it and I'm
just waiting on the patches to land upstream.

My question what is the best practice for this?  It feels that there
should be an easier/quicker way of handling this.  E.g. just tell guix
to use the definition of the current generation for that broken package
and continue with the rest.  Maybe something with the time-machine?

Thanks
-- 
s/Fred[re]+i[ck]+/Fredrik/g

Re: Best practice when dealing with a broken package for guix home?

[Felix Lechner via]

Hi,

On Sun, Jan 14 2024, Fredrik Salomonsson wrote:

> My question what is the best practice for this?

Guix Home is somewhat new. Not everyone uses it. There is some work to
be done somewhere, as you already know.

Any functional package manager will require you to specify a prior
derivation in some form, with a closure over the prerequisites. I don't
think Guix has such functionality, but folks with more experience should
please speak up.

A more practical way to mitigate your issuesn would be to improve the
code quality in the development HEAD. For example, we could accept
commits only when they do not break anything. Technically, a solution
might be around the corner, but there is considerable disagreement in
the project whether such a strict standard should be applied. It would
most likely lead to countless rebuilds and unacceptable delays.

Personally, I went for a simple solution with immediate benefits: I keep
a branch that builds everything I need and advance it only every two
months or so. I called it 'prebuilt.' You can find it as here:

    https://codeberg.org/lechner/guix/src/branch/prebuilt

I know that's not what you wanted to hear, but it's all I can offer at
this time.

Kind regards
Felix

Re: Best practice when dealing with a broken package for guix home?

[Carlo Zancanaro]

On Sun, Jan 14 2024, Fredrik Salomonsson wrote:
> 3) Copy an older definition that works to my custom channel, add a
> prefix and use that until it is fixed.

This is what I do. Or, more accurately, I copy it into my home.scm file
and use the package object directly. That way it's clear why it exists,
and it's easier to remove when I no longer need it.

> My question what is the best practice for this? ... Maybe something
> with the time-machine?

I don't know about best practice, but I think at one point I did use
inferiors for this (which is what time machine users under the hood).
Unfortunately I can't remember why I stopped.

If you'd like to go this way, the documentation in "(guix) Inferiors"
has a short example of getting a package out of a different Guix
version. It's pretty straightforward.

Carlo

Re: Best practice when dealing with a broken package for guix home?

[Fredrik Salomonsson]

Hi,

Felix Lechner <felix.lechner@lease-up.com> writes:

> Hi,
>
> On Sun, Jan 14 2024, Fredrik Salomonsson wrote:
>
>> My question what is the best practice for this?
>
> Guix Home is somewhat new. Not everyone uses it. There is some work to
> be done somewhere, as you already know.
>
> Any functional package manager will require you to specify a prior
> derivation in some form, with a closure over the prerequisites. I don't
> think Guix has such functionality, but folks with more experience should
> please speak up.
>
> A more practical way to mitigate your issuesn would be to improve the
> code quality in the development HEAD. For example, we could accept
> commits only when they do not break anything. Technically, a solution
> might be around the corner, but there is considerable disagreement in
> the project whether such a strict standard should be applied. It would
> most likely lead to countless rebuilds and unacceptable delays.

Yeah, I can see benefits going stricter but also keep it as is.
>
> Personally, I went for a simple solution with immediate benefits: I keep
> a branch that builds everything I need and advance it only every two
> months or so. I called it 'prebuilt.' You can find it as here:
>
>     https://codeberg.org/lechner/guix/src/branch/prebuilt
>
> I know that's not what you wanted to hear, but it's all I can offer at
> this time.

That is fine, thank you for your input.  Interesting idea to keep a
branch of what you need.  Do you apply patches etc if you encounter a
broken package when you advance your branch?  Or how do you deal with
cases when they happen?

-- 
s/Fred[re]+i[ck]+/Fredrik/g

Re: Best practice when dealing with a broken package for guix home?

[Fredrik Salomonsson]

Hi,

Carlo Zancanaro <carlo@zancanaro.id.au> writes:

> On Sun, Jan 14 2024, Fredrik Salomonsson wrote:
>> 3) Copy an older definition that works to my custom channel, add a
>> prefix and use that until it is fixed.
>
> This is what I do. Or, more accurately, I copy it into my home.scm file
> and use the package object directly. That way it's clear why it exists,
> and it's easier to remove when I no longer need it.
>
>> My question what is the best practice for this? ... Maybe something
>> with the time-machine?
>
> I don't know about best practice, but I think at one point I did use
> inferiors for this (which is what time machine users under the hood).
> Unfortunately I can't remember why I stopped.
>
> If you'd like to go this way, the documentation in "(guix) Inferiors"
> has a short example of getting a package out of a different Guix
> version. It's pretty straightforward.

I'll check out Inferiors, thanks for the link.  It sounds like there are
some dragons going that route though.  So step 3 might be the happy
medium.

-- 
s/Fred[re]+i[ck]+/Fredrik/g

Re: Best practice when dealing with a broken package for guix home?

[Felix Lechner via]

Hi Frederik,

On Tue, Jan 16 2024, Fredrik Salomonsson wrote:

>  Or how do you deal with cases when they happen?

I maintain a custom Guix with patches on top, plus my own channel.

Kind regards
Felix

Re: Best practice when dealing with a broken package for guix home?

[Simon Tournier]

Hi,

On mar., 16 janv. 2024 at 18:41, Felix Lechner via <help-guix@gnu.org> wrote:
> On Tue, Jan 16 2024, Fredrik Salomonsson wrote:
>
>>  Or how do you deal with cases when they happen?
>
> I maintain a custom Guix with patches on top, plus my own channel.

Well, for what it is worth, I think the good practise is to send
contributions when something broken on master is fixed and not keep the
fix in your own patched Guix version.

That said, I do not use “guix home” so my way probably does not make
sense.  What I do is that I have separated manifest files.  For
instance, I have emacs.scm for my Emacs stuff, ocaml.scm for my OCaml
stuff, compiler.scm for some compilers that I use, base.scm for all the
basic stuff as coreutils etc.

When one package is broken, it impacts only one manifest.  So it
mitigates the issue for upgrading.

What I am not fully happy is that “guix weather” does not have a
codified exit status.  It had been discussed [1] but no consensus.  It
would ease:

  guix weather -m path/to/manifests/foo.scm \
    && guix upgrade -p path/to/profiles/foo

Cheers,
simon


1: guix weather exit status?
Leo Famulari <leo@famulari.name>
Thu, 08 Jul 2021 16:35:03 -0400
id:YOdhd7FfMOvKjTQe@jasmine.lan
https://lists.gnu.org/archive/html/guix-devel/2021-07
https://yhetil.org/guix/YOdhd7FfMOvKjTQe@jasmine.lan

Re: Best practice when dealing with a broken package for guix home?

[Fredrik Salomonsson]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On mar., 16 janv. 2024 at 18:41, Felix Lechner via <help-guix@gnu.org> wrote:
>> On Tue, Jan 16 2024, Fredrik Salomonsson wrote:
>>
>>>  Or how do you deal with cases when they happen?
>>
>> I maintain a custom Guix with patches on top, plus my own channel.
>
> Well, for what it is worth, I think the good practise is to send
> contributions when something broken on master is fixed and not keep the
> fix in your own patched Guix version.

Agreed.  I should have probably worded my initial question a bit better.
I assumed that the package has already been reported by either myself or
someone else and that patches for it to be fixed was already submitted.
What prompted me to ask this question was [mpv-mpris][0].  Since it's
been broken since at least Dec 26 2023 and is the one that is holding up
my upgrade.  And I'm not trying to single anyone out, I totally
understand things take time especially during holidays.  I just got
thinking if there is a good practice to workaround it while I wait for
it to be fixed.  As doing any of my usual workarounds would require a
bit of work as it was mpv that changed and broke mpv-mpris.

[0] https://issues.guix.gnu.org/68044

> That said, I do not use “guix home” so my way probably does not make
> sense.  What I do is that I have separated manifest files.  For
> instance, I have emacs.scm for my Emacs stuff, ocaml.scm for my OCaml
> stuff, compiler.scm for some compilers that I use, base.scm for all the
> basic stuff as coreutils etc.
>
> When one package is broken, it impacts only one manifest.  So it
> mitigates the issue for upgrading.

I did this before, and while it did helped reduce the impact of a broken
package.  It did complicate my upgrade as I needed to have my own update
script etc.  What I like with guix home is that it can essentially
reproduce my home environment on any of my machines by both installing
the packages needed and configuration.  Which is a huge time saver as I
had the issue when I used Arch that I never really got my home
environment to work the same on my desktop and laptop.

>
> What I am not fully happy is that “guix weather” does not have a
> codified exit status.  It had been discussed [1] but no consensus.  It
> would ease:
>
>   guix weather -m path/to/manifests/foo.scm \
>     && guix upgrade -p path/to/profiles/foo
>
> Cheers,
> simon
>
>
> 1: guix weather exit status?
> Leo Famulari <leo@famulari.name>
> Thu, 08 Jul 2021 16:35:03 -0400
> id:YOdhd7FfMOvKjTQe@jasmine.lan
> https://lists.gnu.org/archive/html/guix-devel/2021-07
> https://yhetil.org/guix/YOdhd7FfMOvKjTQe@jasmine.lan

Didn't know that about guix weather.  I don't really use it that much as
my desktop is generally powerful enough to just chew threw packages that
lacks substitutes.  And I usually starts by upgrading that before moving
on to my laptop and other machines running guix.

-- 
s/Fred[re]+i[ck]+/Fredrik/g

Re: Best practice when dealing with a broken package for guix home?

[Tomas Volf]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

On 2024-01-18 17:59:23 +0000, Fredrik Salomonsson wrote:
> Hi,
> 
> Simon Tournier <zimon.toutoune@gmail.com> writes:
> 
> > Hi,
> >
> > On mar., 16 janv. 2024 at 18:41, Felix Lechner via <help-guix@gnu.org> wrote:
> >> On Tue, Jan 16 2024, Fredrik Salomonsson wrote:
> >>
> >>>  Or how do you deal with cases when they happen?
> >>
> >> I maintain a custom Guix with patches on top, plus my own channel.
> >
> > Well, for what it is worth, I think the good practise is to send
> > contributions when something broken on master is fixed and not keep the
> > fix in your own patched Guix version.
> 
> Agreed.  I should have probably worded my initial question a bit better.
> I assumed that the package has already been reported by either myself or
> someone else and that patches for it to be fixed was already submitted.
> What prompted me to ask this question was [mpv-mpris][0].  Since it's
> been broken since at least Dec 26 2023 and is the one that is holding up
> my upgrade.  And I'm not trying to single anyone out, I totally
> understand things take time especially during holidays.  I just got
> thinking if there is a good practice to workaround it while I wait for
> it to be fixed.  As doing any of my usual workarounds would require a
> bit of work as it was mpv that changed and broke mpv-mpris.
> 
> [0] https://issues.guix.gnu.org/68044

Especially for cases like this, just having your fork into which you
periodically merge from upstream works fairly well.  You can apply the patch
directly to the fork without waiting for upstream to act, and git is smart
enough to handle the merge well.

Creating the fork is bit involved, since guix git authenticated is designed in a
way to make authenticated forks pretty much impossible (assuming you want to git
merge), but after the initial setup (for which scripting exists) there really is
not much work required to maintain it (just occasionally merging the upstream).

So that seems like your best option (and what I do).

Have a nice day,
Tomas Volf

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Best practice when dealing with a broken package for guix home?

[Felix Lechner via]

Hi,

On Thu, Jan 18 2024, Tomas Volf wrote:

> periodically merge from upstream works fairly well.

Hopeful that my patches will eventually get accepted, I carry them
forward---unauthenticated---via rebases.

Kind regards
Felix