Re: Stumpwm Contrib Packages

[John Kehayias <john.kehayias@protonmail.com>]

Hi all,

Bit late here, but as a StumpWM user (and having a module I adopted from someone, but maintained outside of the official contrib repo) thought I would chime in. Though in my personal config right now I use a local checkout of the stumpwm-contrib repo rather than the Guix packages. I think that was easier to set up at first and need to look back at it. (And that reminds me, should contribute that module (scratchpads) to upstream stumpwm-contrib.)

On Sat, Sep 17, 2022 at 02:53 PM, Maxime Devos wrote:
>
> On 11-09-2022 17:02, Trev wrote:
>> Hey Guix,
>> I am trying to decide whether or not to contribute a refactor of
>> stumpwm-contrib in gnu/packages/wm.scm. It feels like each contrib
>> module should be its own package with its own checkout and that it might
>> be a bad idea to update all of the contrib modules through one common
>> ancestor.
>> If you are not familar with stumpwm and stumpwm-contrib, you can see the
>> source repository here:<https://github.com/stumpwm/stumpwm-contrib>
>> The inheritance I am referring to is here:
>> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/wm.scm#n1942>
>> My reasoning for this is that if breaking changes are introduced to one
>> module, but wanted updates happen to another, it would be nice to avoid
>> the breaking changes and get the updates.
>
> If the stumpwm people put lots of components in a single
> 'stumpwm-contrib', I expect that they take care of making sure all the components _within
> a single version_ remain compatible, and that by picking a separate commit for each
> component in Guix, it is likely to encounter incompatibilities (breaking changes).
>

From what I understand and my experience, a few comments:

1. While grouped together in one official git repo, I believe most (all?) of the modules are independent and written as separate lisp packages. I haven't checked this in detail, but that's my understanding; it is useful grouping to have all the stump modules together.
2. I've found the development speed for contrib to typically be on the slower side (less active than the main stumpwm repo, for instance), so I think this makes it less of a concern. Updates tend to be per module per commit, so if something breaks in a commit, moving to a previous commit wouldn't change other modules.
3. I can't say I've had any problems due to any incompatibility between modules and any bug I've hit have been ones that have been lying in wait rather than introduced by current work.

> In the hopefully rare case where we encounter an incompatibility, we can still choose to
> override the checkout for the impacted package.
>

Yes. Or of course locally using a package transformation (include a patch), local definition, or perhaps via the local stumpwm config to override something in the module after loading.

> As such, I recommend keeping the status quo.
>

I can see why someone would want to separate the sourcing, but I think that adds extra maintenance. I could go either way.

John