Re: A script to check an edit does not break anything

["Ludovic Courtès" <ludo@gnu.org>]

Hi Edouard,

Edouard Klein <edk@beaver-labs.com> skribis:

> Ludovic Courtès writes:

[...]

>> However, this is definitely something ‘guix lint’ could check with
>> something along the lines of the patch below.
>
> Thank you for pushing profile-collisions, it certainly is helpful for
> finding such problems, and it perfectly integrates within guix.
>
>>
>>> - Secondly, it does not limit itself to the dependents (as listed by
>>> guix refresh --list-dependents) of the packages one is meddling with,
>>> but to the whole reverse bags (as listed by guix graph
>>> --type=reverse-bag).
>>
>> I think it’s equivalent: ‘guix refresh -l’ simply shows the contour of
>> the graph whereas ‘guix graph’ lists every node.
>
> The problem lies when the leafs are OK but the nodes in the middle are
> not. See for example in the attached image, the failure of jupyter is
> masked by r-irkernel being both buildable and installable.

When you write “the failure of jupyter”, you mean failure to _install_
jupyter, right?

‘guix refresh -l’ returns the set of leaves whose closure encompasses
all the dependents of the given package.  Thus, if you build all the
nodes returned by ‘guix refresh -l jupyter’, you’ll definitely notice a
build failure in jupyter.

> Now, the new tool you added to guix lint solves the discoverability
> problem. It is now indeed reported that jupyter has a problem.
>
> Still, it takes around 10 minutes to run on my (admittedly underpowered)
> machine, and one has to rummage to the output (or diff with a previous
> run) to see if a specific action caused or solved problems.

What takes 10 minutes?  ‘guix lint -c profile-collisions’ without
arguments?

It runs in 2 minutes on my laptop, which is admittedly too much, but
note that most of the time you’ll just run:

  guix lint -c profile-collisions jupyter

That should take a few seconds at most.

> gpwc.sh has a real time visual output that is specific to current
> modifications (it could even be paired with Ricardo's automatic commit
> message writer to automatically guess which root packages to start with)
> that allows the developer to start investing a problem quicker, without
> having to wait for the end of the run. Also, the visual output makes
> seeing who depends on whom easier, the same information in text form
> makes my head hurt.
>
> Provided I rewrite it in scheme, do you think gpwc could make it
> into guix/etc ? 

I haven’t looked in detail at gwpc.sh but I guess we’d all like improved
tooling.  To have it in Guix, it’s better if it’s well integrated with
existing tools and written in Scheme.

Thanks!

Ludo’.