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

[David Bjergaard]

Hi,

Here's the "state of the art" of extensions in stumpwm: Lisp code for an
extension to stumpwm currently exist in contrib.  There is a file called
module.lisp which scans the *contrib-dir* and loads the appropriate
file. The call is from your rc file is: (load-module "blah")

There is lots of room for improving this on the backend, transparent to
the user.  The current "API" for stumpwm is, whatever symbols/functions
are exported by the stumpwm package can be used by an external
extension, if you need access to something that isn't available you can
file a pull request.  

anti-features:
* No support for multiple contrib dirs (think emacs' load-path)
* No way to handle dependencies easily
* Have to request your module be included with stumpwm
* Have to support users through stumpwm's issue tracker
* No ability to require a minimum stumpwm version

Sam summarizes the issues I'm worried/want to change about well: 
> 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.

After chatting in IRC, this is the idea that's crystallizing in my mind
(daimrod, tychoish, futura, and df__ all contributed to this discussion
on irc):
 
* Modules going forward must be asdf load-able and hence quicklisp compatible.
* Module loading can be a matter of (ql:quickload "stump-module")
* Module distribution can happen either via quicklisp's
  quicklisp-projects on github, or you can "git clone" the source into
  ~/quicklisp/local-projects depending on the module author's taste
* (load-module "blah") should be able to check a minimum stumpwm
  version, and handle the (ql:quickload "") for you (as well as loading
  any dependencies)

I wrote up a use case here: https://github.com/sabetts/stumpwm/wiki/Modules

I think this takes care of all my worries about the current state of the
contrib, and it does so in a way that is technologically reachable.  

For the current contrib modules:
* Refactored to become asdf systems and loadable by quicklisp (daimrod
  has done work on this already)
* Moved to their own stumpwm-contrib repo (one for all? I'm not sure)
* Ideally would still be able to (load-module "blah") from you rc to
  avoid breaking rc files

Let me know how this sounds, I appreciate everyone's feedback and
opinions.  I hope we can move forward on this and lower the barrier to
making modules... Then we'll take over the desktops everywhere with
stumpwm!

Cheers,

    Dave