Stumpwm Contrib Packages

Stumpwm Contrib Packages

[Trev]

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.

I have some related contributions to stumpwm-contrib that I would like
to submit but I would rather wait and see what others may think first
and perhaps avoid making the effort to refactor where the effort is not
wanted.

If I run into personal issues with the current pattern, I can always
just "fork" a module into my own channel, after all.

-- 

Trev : 0FB7 D06B 4A2A F07E AD5B  1169 183B 6306 8AA1 D206

Re: Stumpwm Contrib Packages

[Antonio Carlos Padoan Junior]

Trev <trev@trevdev.ca> writes:

> 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.

Hi,

I'm only an user of these contrib packages and I see no issue with your
proposition. IMHO, you can move on. Thanks. 

Regards,
-- 
Antonio Carlos PADOAN JUNIOR
GPG fingerprint:
243F 237F 2DD3 4DCA 4EA3  1341 2481 90F9 B421 A6C9

Re: Stumpwm Contrib Packages

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 1366 bytes --]



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).

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

As such, I recommend keeping the status quo.

Greetings,
Maxime

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: Stumpwm Contrib Packages

[John Kehayias]

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

Stumpwm Contrib Packages

[jgart]

> If I run into personal issues with the current pattern, I can always
> just "fork" a module into my own channel, after all.

Have you tried to use package transformations? Maybe they will work here...


Here's how I got the latest eglot, for example:

guix upgrade emacs-eglot --with-git-url=emacs-eglot=https://github.com/joaotavora/eglot.git commit=emacs-eglot=06e6dd6693123a737fb883dcf277432d63d6518e


Not sure if they'll work in this context given that the stumpwm packages are all grouped together in one repo.

wdyt

Re: Stumpwm Contrib Packages

[Trev]

jgart <jgart@dismail.de> writes:

>> If I run into personal issues with the current pattern, I can always
>> just "fork" a module into my own channel, after all.
>
> Have you tried to use package transformations? Maybe they will work here...
>
>
> Here's how I got the latest eglot, for example:
>
> guix upgrade emacs-eglot --with-git-url=emacs-eglot=https://github.com/joaotavora/eglot.git commit=emacs-eglot=06e6dd6693123a737fb883dcf277432d63d6518e
>
>
> Not sure if they'll work in this context given that the stumpwm
> packages are all grouped together in one repo.

I'm not sure they'd work, either, but pinning my packages in my own
channel, or even just writing a package definition on my own load path
pins the package well enough for me. I also won't have to remember that
CLI command.

>
> wdyt

-- 

Trev : 0FB7 D06B 4A2A F07E AD5B  1169 183B 6306 8AA1 D206

Re: Stumpwm Contrib Packages

[jgart]

On Sun, 18 Sep 2022 09:32:35 -0700 Trev <trev@trevdev.ca> wrote:
> I'm not sure they'd work, either, but pinning my packages in my own
> channel, or even just writing a package definition on my own load path
> pins the package well enough for me. I also won't have to remember that
> CLI command.

That makes sense