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

[wagnerdm at seas.upenn.edu]

I for one am strongly in favor of sane defaults, and I don't think  
current xmonad can really claim that seriously. Breaking up the  
packages this way could enable that.
~d

Quoting Gwern Branwen <gwern0 at gmail.com>:

> 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
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
>