Modular config support

[GoogleCodeExporter]

XMonad.Core.recompile passes "-i" to ghc when compiling
~/.xmonad/xmonad.hs, making it impossible to break a configuration into
multiple modules.  This issue was previously discussed at:
  http://www.haskell.org/pipermail/xmonad/2008-July/006106.html
but no resolution was reached.

Unfortunately, simply removing "-i" from the ghc arguments poses two
problems: (1) As discussed in the above thread, on case insensitive file
systems "import XMonad" will try to import "xmonad.hs" instead of the
XMonad module and (2) recompile's simple recompilation checker won't notice
changes to modules, since it only checks the modification time of xmonad.hs.

Personally, I'm not so concerned about (2), which could be fixed if
necessary using GHC's dependency generation mode.  (1) is a bigger problem,
for which I see a few possible solutions:

a. Change the name of the configuration file so it doesn't conflict with
any XMonad modules it may try to import.  For example, rename it to main.hs
or startup.hs or even config.hs (though the last one may cause confusion).
 This seems like the cleanest solution to me, but has obvious compatibility
drawbacks.  At least temporarily, recompile could check for the presence of
either main.hs or xmonad.hs and continue to compile the latter with "-i",
perhaps issuing an xmessage warning.

b. As suggested in the thread, create a convention for where to put
configuration-local modules, such as "~/.xmonad/lib" and pass this as the
"-i" argument.  Unfortunately, this behavior is unintuitive.

c. Allow the user to specify their own "-i" argument, perhaps in a plain
text file in ~/.xmonad/ or a magic comment in xmonad.hs.  This solution
seems like a hack and could lead to nasty surprises for people who try to
put "." in their import path.

I'd be happy to code up a patch for any of these if there's consensus.

Original issue reported on code.google.com by amdragon@gmail.com on 24 Oct 2008 at 8:40

[GoogleCodeExporter]

There's always option 'd', do nothing.

Option a requires a major user intervention; if we were going to do that, then I
think we should blow our capital on something more valuable.
Option b harms usability.
Option c may not harm usability, but if it does, it'll really hurt that user 
who runs
into a problem.

Option d is well-understood; there doesn't seem to be a huge need for 
multi-modular
xmonad.hses; and I'm not convinced that one *should* have xmonad.hses which are 
that
enormous. If they are that large, then perhaps one should be looking into
contributing modules or functions or features upstream, seeing whether there are
better ways to accomplish things, or just generally rethinking the xmonad.hs.

Original comment by gwe...@gmail.com on 24 Oct 2008 at 9:36

[GoogleCodeExporter]

I agree with Gwern here. Any of the proposed options would be a lot of effort 
and/or
pain for not much benefit.

Original comment by byor...@gmail.com on 25 Oct 2008 at 8:10

[GoogleCodeExporter]

All good points, though the premise, at least in my mind, was not for enormous
xmonad.hses, but rather because Modularity is Good.  I have lots of little 
things in
my xmonad.hs like custom loggers and prompts, as I imagine many people do, for 
which
it would make sense to isolate the code and dependencies in separate modules. 
Furthermore, encouraging people to modularize such code now would make it easy 
to
move them into xmonad-contrib as they grew and become more generally useful.

However, if this is an unusual way to use xmonad.hs, then I agree that 
providing two
configuration options for the sake of modularity may be overkill (though I 
disagree
that asking the user to rename a file at their convenience constitutes "major 
user
intervention").  If there is a more warranted configuration change that 
requires user
intervention anyways (such as the past one from Config.hs to xmonad.hs), then 
please
take this issue into consideration.

Original comment by amdragon@gmail.com on 25 Oct 2008 at 11:35

[GoogleCodeExporter]

I don't see how option (b) "harms usability", because AFAICT it doesn't break 
any
existing working setup (unless someone already uses ~/.xmonad/lib for another
purpose).  It's trivial to change "-i" to "-ilib" in XMonad.Core, so it's not 
much
effort and not much pain for moderate benefit.  Right now I have to put a ghc 
wrapper
on my path to override how xmonad invokes ghc; that's pain.

Original comment by beneficial.terminator@gmail.com on 20 Mar 2009 at 2:20

[GoogleCodeExporter]

Currently the primary problem is that our recompilation checker only checks
.xmonad/xmonad.hs.  I think it would not be nice to allow the user to place 
files in
.xmonad/lib yet fail to rebuild xmonad when the files are changed.

Original comment by SpencerJ...@gmail.com on 20 Mar 2009 at 2:36

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I see. Not that changing -i to -ilib would break anyone's setup, but what's the
rationale behind not just using ghc's recompilation checker? Sorry I'm new to 
this.

Original comment by beneficial.terminator@gmail.com on 20 Mar 2009 at 2:42

[GoogleCodeExporter]

How about this patch for checking if any files in ~/.xmonad/lib have changed?

Original comment by vogt.a...@gmail.com on 20 Mar 2009 at 3:28

Attachments:

• libpath.dpatch

[GoogleCodeExporter]

Sorry, I accidentally reverted to -no-recomp: here's the amended patch

Original comment by vogt.a...@gmail.com on 20 Mar 2009 at 3:40

Attachments:

• libpath.dpatch

[GoogleCodeExporter]

What about hierarchical modules?  Do we need to follow symlinks?  (Does GHC 
follow
symlinks?)

Original comment by SpencerJ...@gmail.com on 20 Mar 2009 at 3:45

[GoogleCodeExporter]

GHC (6.10 at least) follows symlinks to hs files at least, so to keep things
categorized yet accessible:

make a regular xmonad hierarchy. Write source in ~/.xmonad/lib naming those 
modules
with the proper hierarchical name, then link those modules to their hierarchical
spots in that hierarchy. (this last part could/should be automated (put into
contrib?) ... it is a bit inconvenient)

Interestingly, my ghc will compile the module in the search path if the same one
exists in a package, so testing modifications to modules (or moving them into
contrib) does not require any change to xmonad.hs imports.

Original comment by vogt.a...@gmail.com on 20 Mar 2009 at 4:05

[GoogleCodeExporter]

My point about hierarchical modules is that they make a nested directory 
structure,
meaning we need to recursively descend the hierarchy.  In the case of symlinks, 
we'd
need to resolve the symlink to get the modification time of the file pointed 
to, not
the modification time of the symlink itself.

Original comment by SpencerJ...@gmail.com on 20 Mar 2009 at 4:16

[GoogleCodeExporter]

If we only look at files at the top level, but let ghc traverse the directories
underneath that are populated by symlinks I think we can get hierarchical 
modules and
keep the simpler recompilation checking.

Original comment by vogt.a...@gmail.com on 20 Mar 2009 at 4:21

[GoogleCodeExporter]

ok, now checking for newer files anywhere in ~/.xmonad/lib, it does follow 
symlinks
(no symlink cycle checking...).

Original comment by vogt.a...@gmail.com on 20 Mar 2009 at 5:59

Attachments:

• libpath.dpatch

[GoogleCodeExporter]

Issue 293 has been merged into this issue.

Original comment by SpencerJ...@gmail.com on 7 May 2009 at 12:13

[GoogleCodeExporter]

Here's another idea: if xmonad.hs contains just

import XMonad
main = useModularConfig

then xmonad reloads again using whichever modular
config scheme we choose. That does slow things down,
but then we can also provide a command-line flag
that skips directly to modular without worrying about
compatibility issues. We are then free to choose whichever
scheme we prefer for modular configuration.

We could also arrange things so that if xmonad.hs is
not the above, old-style config files would still work
as always even with the --modular command line
flag. That requirement would slightly limit us in our
choice of modular scheme though.

Original comment by YitzG...@gmail.com on 22 Jul 2009 at 9:35

[GoogleCodeExporter]

The patch that extends the ghc search path to ~/.xmonad/lib has been applied.  

We still need some documentation for this feature.

The man page blurb sjanssen requested is here:
http://www.haskell.org/pipermail/xmonad/2009-September/008473.html

Original comment by vogt.a...@gmail.com on 3 Sep 2009 at 6:41

[GoogleCodeExporter]

Done except the documentation patches are unapplied, so I won't close this one 
just yet

Original comment by vogt.a...@gmail.com on 17 Oct 2009 at 3:02

• Changed state: Started
• Added labels: Milestone-Release0.9

[GoogleCodeExporter]

Original comment by vogt.a...@gmail.com on 21 Oct 2009 at 4:25

• Changed state: Patch
• Added labels: Component-Core

[GoogleCodeExporter]

Original comment by vogt.a...@gmail.com on 21 Oct 2009 at 4:42

• Changed state: Verified