[xmonad] XMonad.Actions.Volume

wagnerdm at seas.upenn.edu wagnerdm at seas.upenn.edu
Fri Jun 19 14:46:26 EDT 2009


Quoting Brent Yorgey <byorgey at seas.upenn.edu>:

> On Thu, Jun 18, 2009 at 08:30:20AM -0400, wagnerdm at seas.upenn.edu wrote:
>>
>> This is probably something of a controversial patch: it adds two
>> dependencies.  I don't think the "parsec" dependency is a big deal, since
>
> Hmm.  I'm not sure how I feel about the extra
> dependencies. (Literally---I'm not using "I'm not sure how I feel" as
> a euphemism for "I don't like it").  But I thought I should point out

Right, the more I think about it, the more I recognize that extra  
dependencies of any kind could be a problem for xmonad-contrib.  I  
recognize that the target audience includes non-Haskell people who  
can't really be expected to (and shouldn't really have to) understand  
the Haskell library landscape.  On the other hand, the library  
landscape is there precisely so that people who do know Haskell can  
use it. =)

I haven't decided what I want to do about this yet.  The way I see it,  
I have two choices if I want to publish this for other people to use  
(and in either case, the patch I sent previously should not be applied):

1. Rip out code from Data.List.Split and convert the Parsec stuff to  
ReadP.  This sucks because I'd have to waste time rewriting the code,  
it would make me feel icky to duplicate code from other libraries, and  
it wouldn't really settle the issue for people who want to write  
contributions in the future that depend on libraries with less obvious  
counterparts.
2. Publish a separate package.  This sucks because it means it  
wouldn't be in the "blessed" collection of code we call  
xmonad-contrib; people would be less likely to find it, they would  
waste more time duplicating it if it was something they wanted, and  
they would file fewer bug reports.

I am open to suggestions.
~d


More information about the xmonad mailing list