[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Stumpwm Contrib Packages
From: |
John Kehayias |
Subject: |
Re: Stumpwm Contrib Packages |
Date: |
Tue, 04 Oct 2022 21:50:16 +0000 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Stumpwm Contrib Packages,
John Kehayias <=