Re: [STUMP] Stumpm-2.0, Dependencies and Modularization

[David Bjergaard]

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


Javier Olaechea <address@hidden> writes:

> 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