[xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS Small announce about the completion of the bluetile merge

[Gwern Branwen]

On Mon, Dec 7, 2009 at 7:27 PM, Gwern Branwen <gwern0 at gmail.com> wrote:
> On Mon, Dec 7, 2009 at 4:34 PM, Wirt Wolff <wirtwolff at gmail.com> wrote:
>> A bluetileConfig could also play a role similar to the template
>> config in providing a reference for people picking and choosing parts
>> of the bluetile configuration, or wanting to activate them all plus
>> a few customizations.
>>
>> Thanks for bearing with the long-winded saying of:
>> * Yes I agree they should continue as synced separate projects.
>> * Some of the bluetile server commands should be available from contrib.
>> * There should be a bluetileConfig providing all but the dock and greeter
>> bits from bluetile. As much as possible normal Config.Foo customization
>> methods should work, and any deviations be well documented and include
>> integration helper functions if needed.
>>
>> regards,
>> --
>> wmw
>
> Here's something I've been thinking. What if we came up with an
> xmonad.hs that included all the stuff everybody asks for and the
> obvious newbie aids like a first-run xmesage prompt? (Let's call this
> a standardConfig, as opposed to barebonesConfig or pimpedOutConfig.)
>
> Then we could take the current xmonad package, rename it
> 'xmonad-core'*; the new 'xmonad' would be basically a cabal file
> depending on xmonad-core and xmonad-contrib, and an executable reading
> 'Main.hs...importXMonad...import XMonadContrib.StandardConfig...main =
> xmonad standardConfig'. (xmonad-core's executable would be left alone
> of course.)
>
> If we get ambitious, the new xmonad main could do more. Perhaps we
> could check for XineRama in main and then modify our standardConfig to
> use SmartBorders or not?
>
> This, I think, could make everyone happy:
>
> - The people concerned about keeping the core minimal and pure can
> tell anyone suggesting 'hey, let's make SmartBorders the default
> layout' to change the standardConfig and leave the core alone. The
> tension between a default that is on par with TWM or raw X and a
> bloated failing awesome-like core goes away.
> - People who really want the stripped down xmonad have a name which
> makes it very clear which one of 'xmonad', 'xmonad-core', and
> 'xmonad-contrib' they want.
> - Distro & package maintainers bear very small costs since the package
> is really small and simple. Quite possibly it may not need updating
> for years or indefinitely once we get dynamic linking. (Since, if I
> understand the idea right, the compiled program would not hardwire the
> xmonad libraries but point to libxmonad.so or something, and would get
> new versions of 'xmonad' and 'standardConfig' everytime the respective
> libraries were changed.)
> - The majority of our users' lives will be easier: by installing
> 'xmonad', they get the core and -contrib as dependencies, and they
> don't have to struggle to get a comfortable setup. Sane defaults. I
> think we could make a standardConfig which is competitive with fluxbox
> or ratpoison. Even if a user doesn't want the spartan -core, but
> dislikes the standardConfig, they could still be better off, since
> it's unlikely they dislike the entire thing or even most of it. It
> seems to me that most people tend to dislike 1 or 2 things; if a
> person dislikes only 1 thing, they ideally will only have to change
> one thing.
> - People with existing configs are entirely unaffected. Because module
> names are split from package names, their xmonad.hs will never know
> the difference. (Presumably the new xmonad executable will see the
> xmonad.hs and recompile/run it rather than continue with
> standardConfig.)
> - This idea is better than some separate 'bluetile' executable
> package. dons and others have spent years publicizing xmonad. People
> who want xmonad install 'xmonad'. The people who would benefit from it
> are almost by definition the people who would not know about it until
> too late.
>     Nor can we add an executable section to XMonadContrib for exactly
> the same reason. Someone just trying out XMonad may well never install
> -contrib or even know about it until they begin complaining. If you
> knew little about Xmonad and saw  the Debian description at
> <http://packages.debian.org/sid/xmonad> would you be able to instantly
> infer 100% of the time that "Xmonad is configured in Haskell, and
> custom layout algorithms may be implemented by the user in config
> files" implies that there is an enormous collection of extensions &
> customizations called xmonad-contrib? I mean, -contrib isn't even a
> recommended or suggests!
>
> The major downsides I can think of:
>
> - hardcore minimalists might complain that they have to relearn to
> 'install xmonad-core' rather than 'install xmonad', lest they pull in
> -contrib as well. But then, these tend to be the people best able to
> bear the costs; I cannot weep for them.
> - the documentation might become misleading in places. Perhaps not
> majorly; many problems will be averted by the fact that the old
> 'xmonad' executable could always be reached as 'xmonad-core', and to
> do anything programming-wise would require using module names, and
> since the new xmonad depends on xmonad-core, there'd be no breakage.
> To be consistent, we might want to rename the darcs repo to
> .../xmonad-core; but then, the new 'xmonad' is so small we could just
> tuck it away in its own directory, or make the repo have 2 top-level
> folders, xmonad-core & xmonad.
> - this requires effort and approval from many people.
>     (How many distro maintainers do we have? 3 or 4? Toss in another
> 3 for the -core devs, and then maybe a few more for people in favor of
> the general idea of a default userfriendly config but really couldn't
> we just make it another XMC module or something. Hard to have a
> consensus or get anything done with 10 people complaining, and this
> doesn't work if the official xmonad package doesn't change. It can't
> be done as a fork, as I covered above.)
>
> * this is what everybody in #xmonad seems to say to distinguish the
> core package from contrib, anyway

Has anyone thought about it since? It's not at all uncommon in #xmonad
to see people having issues with adding common config options that I
think this proposal would address.

-- 
gwern