Andreas Enge <[email protected]> skribis: > On Mon, Jan 12, 2015 at 05:26:02PM +0100, Ludovic Courtès wrote: >> To begin with, we could have a “weechat” package with a “reasonable” >> option set: >> (define weechat >> (make-weechat "weechat")) >> >> And possibly another variant with, say, all the options enabled: >> (define weechat-full >> (make-weechat "weechat-full" #:python? #t #:lua? #t)) > > So far, our policy has rather been to enable all possible inputs. I think > this should be the default with the name "weechat" unaltered. If need be, > one could add another package with fewer inputs under the name > "weechat-small" or similar. > > What do others think? If there is consensus, we could formalise something > in the package naming section of the manual.
Actually yes, weechat/weechat-small (rather than weechat-full/weechat) is a good choice, and it’s what we did for Emacs notably. Sorry for the confusion. > Apart from that, I do not see why having several scripting languages enabled > is a problem; in the end, it is quite likely that they are present anyway due > to one package or another (it is rather difficult to avoid perl and python > these days!). So my real preference would be to not have such "...-small" > packages except for outrageously big default packages (texlive comes to > mind here...). Well, pulling Python, Ruby, Lua, and Guile just to get an IRC client really seems overkill. In general, Guix is not about space-efficiency, but we still want to make it easy to avoid adding extra weight when it’s clearly unnecessary. >> A long term possibility would be to officially support something like >> Gentoo’s “USE” flags. These would be declared as part of the package, >> and the build process would take them into account somehow: > > To me, this sounds like overkill to solve a problem that I am not > convinced exists. Well, less code is better, and it could be that the full/small package variants are enough in many cases. We’ll see. Ludo’.
