Very well put, Joram.
On Dec 9, 2014 11:48 AM, "Joram Schrijver" <
address@hidden> wrote:
Hi,
As I see it, there are two things involved here:
1. Moving some of the elsewhere useful functionality into libraries
2. Refactoring internals to improve decoupling of mostly-unrelated
functionality.
I'll first address the second point, since I see it as somewhat of a
prerequisite for the first.
As it is right now, closely related functionality is often implemented
in different parts of the codebase. This makes changes harder than
needed because you'll have to first find out what assumptions the
different users of the code make. It makes maintenance hard and new
development harder.
This is a lot of work to fix, because it requires changes to practically
the entire codebase. I think it's worth it though.
An approach that could work is to use one package per file. I've seen it
used quite a bit recently and ASDF supports it through its
package-inferred-system extension.[1][2] Doing this basically forces
thinking about an API for the different types of functionality that are
implemented. There are, right now, a group API and a window management
API in the codebase, but because everything is in the same package
there's no obvious separation between implementation and interface.
I hope to have some time in the next few weeks in order to try this
approach and see if it helps. It doesn't need to happen all in one go,
so experimentation is possible.
When the StumpWM codebase is less coupled, turning parts of it into
separate libraries should be a lot easier. Then including those
libraries in the build process is the next problem.
Right now StumpWM only uses Quicklisp on LispWorks, to try to install
it. For other implementations there's no dependency on Quicklisp, only a
recommendation in README.md. The loading of dependencies is not handled
any further. The simplest way to go about an increase in dependencies is
probably to use the same approach we're using right now: mostly ignore
it. Most Common Lisp projects don't really do anything more, depending
on the user to figure it out by using Quicklisp or some other means.
For a project like StumpWM, that isn't aimed just at Common Lisp
programmers, adding more dependencies might make this approach too much
of a hassle, because every dependency would make installing StumpWM
more work. That could be solved by including any dependencies in the
release somehow (git submodules?), or by downloading them during the
build process.
Of course at that point we're in Quicklisp territory. I personally think
it might be interesting to see if including Quicklisp is feasible.
There's the potential of using a custom "dist" to load modules and
dependencies from the internet. I have no idea if this is actually
possible and/or a good idea, but I think it's worth looking into.
Long story short, I think a first priority should be to organize the
StumpWM codebase better. It makes the code more maintainable and makes
it easier to turn parts of it into separate libraries. This is a bit of
a big project, but it can probably be done piece by piece once an
approach is chosen. For installing dependencies multiple approaches can
be chosen and I don't think we should dismiss Quicklisp just yet.
--
Joram
[1]:
http://common-lisp.net/project/asdf/asdf/The-package_002dinferred_002dsystem-extension.html#The-package_002dinferred_002dsystem-extension
[2]:
http://davazp.net/2014/11/26/modern-library-with-asdf-and-package-inferred-system.html
On Tue, Dec 9, 2014, at 04:35 PM, David Bjergaard wrote:
> Hi All,
>
> There was some talk on the issue tracker a while back about factoring
> out StumpWM's useful bits so they could be used in other projects. In
> addition there are some parts of stumpwm which have obvious boundaries
> (floating vs tiled groups).
>
> The arguments for are obvious. The arguments against are:
> - Increases StumpWM's external dependencies
> - Complicates the build process
> - Increases barrier for people packaging StumpWM for distros
>
> I'm thinking that most of the arguments against could be glossed over
> with appropriate Makefile rules. I'm open to other suggestions. I
> suppose some sort of lispy solution might be in order. I think we would
> have to handle the following cases:
>
> - users already have dependencies installed via quicklisp
> - users have dependencies installed via distro's package manager
> - users don't have any dependencies and need them checked out.
>
> I don't want to reimplement quicklisp in stumpwm. I don't want to
> depend on quicklisp for the actual build process. (Right now its used
> to get dependencies, but as part of the pre-reqs not the actual build
> that is driven by make).
>
> I'm hoping we can have a discussion here to help codify a way forward,
> because I think there is great value in having the packages available
> for other lisp hackers (myself included for a project I have cooking).
>
> Dave
>
> _______________________________________________
> Stumpwm-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
_______________________________________________
Stumpwm-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel