Hi, On Fri, 24 Jan 2020 at 23:06, ison <i...@airmail.cc> wrote:
> My understanding of the global definitions they're talking about is that > they would just be meta objects, not global preferences. > For example (maybe it won't look like this, but just a guess): > Instead of passing the arguments "mpv" and "3.7" into your function you'd > give the parameters: > '((video-player . "mpv") > (python-version . "3.7")) > to the package. > video-player and python-version would be globally defined meta objects > that just give descriptions about what these parameters should be used for > and such (so users can read more information about package parameters when > looking up packages). But the actual values that get used by the package > are not global, they're passed into the package just like your function > example. Maybe I misread something and/or I misunderstand other thing but the symbols 'video-player' and 'python' need to be defined somewhere. And with this proposal adding the field 'parameters', this somewhere is outside the package. Therefore, I will end up to a big mess, IMHO. Let consider the packages 'foo' and 'bar'. They depend both on say the 'video-player' package. Well, the definition looks like: --8<---------------cut here---------------start------------->8--- (package (name "foo") (...) (parameters video-player) (...)) (package (name "bar") (...) (parameters video-player) (...)) --8<---------------cut here---------------end--------------->8--- Now, the user wants to install the both packages but: - they requires that "foo" depends on vlc without any X support, say "vlc-no-x" - and they require that "bar" depends on full "vlc" So how to do? Where is defined 'video-player'? How to install the both packages with the same transaction? > I'm not sure with the function method how easy it would be to inform the > user of all available options. For example when running `guix search` > would it be able to programmatically collect all the options that a > package has and display them there? To me, the "official" packages in master should stay "simple" with no parameter. Otherwise, it is will hard -- if not impossible -- to ensure that all combinations work; or the number of parameters will be very limited. However, Guix should provide more tune-able rewriting package functions. And these modified packages should live in channels; possibly official ones to be built by Berlin (substitutes). > Also it seems that whether or not there are global meta objects is a > separate issue than whether to use parameters or functions. It looks like > either method could use them or not. In the function approach you could > still just pass in an alist as above. Yes. But the big differences are: 1. the base package is untouched 2. the arguments are locally defined 3. everything is explicit So less surprises IMHO. Well, I really do not know and I do not have a strong opinion: I just fear that the 'parameters' field would add complexity which would lead to unmaintenable packages. All the best, simon