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

[Sam Kleinman]

On Saturday, February 08 2014, 11:28:10, David Bjergaard wrote:

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

Ah, then I think we're understanding the term "submodule" to refer to
different things. Git submodules, (i.e. the bits that allows you to embed
git repositories into a larger repository) feel very "wrong" because
they're clumsy and attempt to solve the "synchronizing compatibility
requirements between different modules." Which isn't really the problem
we have.

> 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 sort of seems like we're trying to solve a number of different,
related problems:

1. Distributing extensions. We want to stop packaging modules in our
   core repository and installation.

2. Maintaining extensions. We want to stop having to review and test
   extensions in addition to work on the core window manager.

3. We want to facilitate a more robust method for loading extensions
   into core.

1 and 3 are technological. 2 is social.

We discuss 3 below, there are solutions most aren't terribly
intrusive. I don't think there's anything objectionable (or difficult)
about 1, though there are different implementations with various merits
or demerits.

On the one hand, perhaps people should just create modules as separate
packages in quicklisp (people do this for python applications in PyPi
all the time.) If we don't want to be in the business of managing
distribution of our own extensions then perhaps we should just punt up
on this.

On the other hand, it seems like most "window manager features,"
particularly for the kinds of features that people likely want from WMs
like stump, are probably best implemented as extensions and if we make
our extension support and interface *better* then there'll be a point in
the not to distant future where stumpwm is the extensions, so maybe it
makes sense to remain involved for a little while. Particularly if
people's experience of stumpwm depends on the quality of the
extensions. (Not that we shouldn't go through the )

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

Yeah, I think load-module should get smarter, or at least making
load-module smarter (throwing warnings when you name modules bypaths?)
version control. Letting modules exist in their own namespaces. Etc.

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

I've only used the former, rather than the latter. I can't really speak
to general practice. Maybe we introduce a warning for the degenerate
behavior in 0.9.9?

Cheers,
sam

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