stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] (sub-modules) / Contrib


From: David Bjergaard
Subject: Re: [STUMP] (sub-modules) / Contrib
Date: Sat, 08 Feb 2014 11:28:10 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Hi Sam,

Responses inline:
Sam Kleinman <address@hidden> writes:

> On Monday, February 03 2014, 02:54:06, David Bjergaard wrote:
>
> [snip]
>
> 1. I think sub modules aren't even really the right answer here. Just a
>    separate contrib repository, should do the trick. I'm also under the
>    impression that the API, such as it is, for extensions is reasonably
>    stable. 
I want to lower the barrier for providing useful code and maintenance.
If modules are passed around as git urls, then writing your own module
and maintaining can be completely decoupled from the development of
stumpwm.  This also creates a logical partition for issues, bugs, and
pull requests as well. Maintaining a separate contrib repository just
divides the contrib issues from core issues, it still requires someone
monitor pull requests/issues as well as acting as a "gate-keeper" for
which modules get included and which don't.

It may be as simple as writing some code that iterates over a list of
git URLs and clones/pulls them.  Then if a user wants to add their own
module that someone else has written but isn't yet on the "official"
list, its just a matter of appending it to the module file in their copy
of stumpwm.
> It might be good to provide extensions with a way of saying
>    "I require at least version y of stumpwm."
Adding this wouldn't be very hard, and it would be a useful extension of
load-module. 
>
> 2. I don't think it's correct that pulling contrib out will break
>    configuration files: you have to explicitly state the path of your
>    contrib directory, so it seems that if we update the installation/build
>    process correctly (which shouldn't be that hard) nothing will be
>    broken. Basically: this seems like a really solvable packaging
>    problem.
You're right that this can be done in a way that doesn't break
configuration files as long as everyone is using (load-module
"module.lisp") and not (load "/path/to/contrib/module.lisp") but I know
that I've seen the latter far more often then the former in example rc
files. It could just as easily become (load-module "module") where
load-module expands to a call like:
(load "/path/to/contrib/module/module.lisp")

>
> Cheers,
> sam
>
> --
> Sam Kleinman (tychoish):
>  - address@hidden
>  - tychoish <http://tychoish.com/>
>  "don't get it right, get it written" -- james thurber
Cheers,

    Dave



reply via email to

[Prev in Thread] Current Thread [Next in Thread]