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): - ga...@tychoish.com - tychoish <http://tychoish.com/> "don't get it right, get it written" -- james thurber _______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
