[STUMP] Stumpm-2.0, Dependencies and Modularization

David Bjergaard

2017-01-11 20:58:24 UTC

Hi Javier,

Thanks for this comprehensive overview of the current state of the codebase. I
have to admit, I'm struggling to find the points that you reference, though I
remember making them.

To be clear, I support added dependencies if they make sense and are a clear
benefit (ie provide a clear purpose and decrease maintenance overhead). There
are vocal users of StumpWM who really prefer the "implement everything and the
kitchen sink" approach that Stump currently takes. This has two immediate
benefits:
1. StumpWM can be ported to many lisp flavors (and the codebase does this
relatively well)
2. StumpWM controls how everything is done (ie we are insulated from shifts in
apis in other packages or if other packages become unmaintained etc)

I want to release one last version of StumpWM under this paradigm.

After this release, development on stumpwm should focus on re-organizing the
code into manageable, modular, packages. The build process should be changed to
support sbcl only, and support for non-sbcl implementations should be dropped.

As far as packaging goes: Its not on us to determine how hard/easy it is for
package maintainers to do their job. If we can provide a build processes that
creates a binary that can be loaded, then the package maintainers must figure
out how to handle the dependencies properly.

Given these goals I don't want to merge any more non-bugfix PRs until we release
1.0.0. After that I expect releases to happen more often. Its been nearly two
years since our last release and we've squashed a lot of bugs.

Sincerely,

David

Post by Javier Olaechea
Hello everyone,
This is email is to follow-up on David's November email regarding dependencies and with the discussion on issue 301 regarding about reorganizing the code base.
Regarding dependencies I think David summed up the trade-offs fairly well. Although I think we are erring a little on the side of caution regarding Alexandria and
split-sequence. Alexandria is almost part of CL and functionality it provides such as PARSE-BODY is essential to proper handling of declaration in macros such as
DEFCOMMAND, which is currently assumes docstrings go before declarations.
Point 2 is generally true, but not in the case Alexandria and split-sequence as they are mostly done and change very little, if at all.
Point 3 is not generally true, because for a package to be accepted to quicklisp it has to run in more than one lisp implementations most libraries are work across all
active implementations. Also some libraries provide cross-implementation shims (Bordeaux-threads, trivial-backtrance, etc.). But it is true that GUI libraries, especially
common-qt can be tricky to get working.
Making StumpWM SBCL-only has benefits and drawbacks. I think however the benefit outweight any drawback at this point. Dropping support for other
implementations would enable us to easily access OS functionality like pipe, select, etc. through sbcl's sb-posix and sb-unix packages.
Regarding the use of cl-ppcre, it is used in other places besides the CLX parsing, the function PARSE-DISPLAY-STRING can be removed,
CLX:GET-DEFAULT-DISPLAY provides the same functionality. Or were you referring to its use in PARSE-XINERAMA-HEAD?
I think the most important concern we should keep in mind when adding a dependency is ease of packaging and distribution. I have no experience deploying lisp to
users but we could look into Dimitri's ql-to-deb to generate a deb file or cl-launch. IIUC ql-to-deb allows the creating of .deb files pulling the dependencies from
quicklisp at build time so that the users don't need to have quicklisp themselves. This would allow us to leverage libraries from the ecosystem w/o worrying about
impacting negatively distribution. cl-launch lets the us create executable lisp 'scripts' which can pull dependencies from quicklisp when run. I know it has a deb package
for itself but I don't know if it expects the user to install quicklisp themselves or not. It would be a good idea to look into these options mid-term.
To sum up, I would be in favor of adding Alexandria at the very least (and split-sequence ideally) and depend only on SBCL.
Regarding modularization, We have to remember that taking chunks out of files to a new file makes it harder to access the pertinent information stored in the commit
logs of the VCS regarding that chunk. But we should try to move stuff like timers, hooks and keymaps to their own file and package (and maybe ASDF system). If we end
up using cl-launch it could even make sense to move them to their separate repository but otherwise it would be wiser to keep them in repository for ease of
distribution.
In an experimental branch I moved timers to its own package and file but now that we use locks for timers, which are defined on wrappers.lisp it would be more
difficult to split-out. Also if we go SBCL this would be moot as we could use sb-timer, which have the advantage of using a priority queue to keep the timer list sorted on
insertion instead of calling sort after each insertion.
Another priority for version 2 is to move logging to be filed based by default. In the same experimental branch as above I successfully used Piping to do so, but it pulls to
many dependencies so it would be better to provide the logging functionality ourselves. Note that although I haven't run into any issues myself, Robert Smith mentioned
that Pipping conses to much, which makes sense as it makes heavy use of CLOS.
My 2c,
Javier Olaechea