[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Sam Kleinman
Subject: Re: [STUMP] (sub-modules) / Contrib
Date: Tue, 18 Feb 2014 00:19:42 -0500
User-agent: mu4e; emacs 24.3.6

So just to be clear: we should totally use ASDF, and using ASDF is
enough for quicklisp. I think quicklisp is a good thing, and I think
that all or most of the *current* hard core stump users are also
quicklisp users. That's great. I just want to make sure that when we
design the workflow for installing contrib modules we have something
that makes sense for users who aren't necessarily like us.

(I think the emacs analogy is decent. And to be fair, I compile emacs
myself, from sources but I don't expect that other people will do the


On Monday, February 17 2014, 11:05:20, David Bjergaard wrote:

> Hi Sam,
> Sam Kleinman <address@hidden> writes:
>> On Sunday, February 09 2014, 08:05:20, David Bjergaard wrote:
>>> * 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:
>> My primary lingering concern is about packaging and distribution. While
>> I suspect most users use Stump by installing it from git, I think that
>> we should be able to ship "binary" packages that don't depend on having
>> quicklisp (or even really lisp itself) installed on their system.
>> Why? This works great with people installing via a package manager, and
>> I think does a *lot* to lower the barrier to entry for new users. While
>> I think most users will eventually compile themselves, I think it's
>> disadvantageous to insist that everyone *must* be a devoted
>> common-lipser to use stump.
>> I think the packaging discussion is larger and more expansive than the
>> discussion about contrib (and we don't have to solve all the pieces of
>> packaging now,) but I want to make sure that there's a path for people
>> who use stump but *don't* have quicklisp installed to be able to access
>> some of contrib (particularly if contrib ends up containing a
>> significant amount of Stump functionality.)
> I agree with all of you're points, especially lower barrier to entry for
> new users, as well as ease of getting stumpwm into major distros like
> ubuntu/debian, arch, fedora.
> Here are my goals:
> 1. Low barrier to install and run stumpwm (if you can run/use emacs, you
>    should be able to run/use stumpwm)
> 2. If you can configure a  .emacs, you can configure a .stumpwmrc (note:
>    this implies that you don't need to know lisp to write your .stumpwmwrc!)
> 3. Low barrier to hack and distribute modules:
>    (quickproject:make-project "module-foo"), hack, distribute
> As I understand quicklisp, its packages/systems are asdf2 loadable.  I
> take this to mean that if I use quickproject to make a project, I don't
> necessarily need quicklisp to load and run the project.  Quicklisp just
> organizes downloading and installing dependencies, it doesn't prevent
> you from distributing code outside of quicklisp.  I think the emacs
> analogy is package.el vs emacs-goodies on debian, vs downloading the
> *.el files from emacswiki.
> I apologize to any vim users, emacs is the elephant in the room when it
> comes analogies here...
> Cheers,
>     Dave

Sam Kleinman (tychoish):
 - address@hidden
 - tychoish <>
 "don't get it right, get it written" -- james thurber

reply via email to

[Prev in Thread] Current Thread [Next in Thread]