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:
>> The inheritance I am referring to is here:
>> 
>> 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

Re: Stumpwm Contrib Packages

[jgart]

On Sun, 18 Sep 2022 09:32:35 -0700 Trev  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

Re: Stumpwm Contrib Packages

[Trev]

jgart  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

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

[Maxime Devos]

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


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Stumpwm Contrib Packages

[Antonio Carlos Padoan Junior]

Trev  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

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