From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: Parameterized packages Date: Sun, 26 Jan 2020 20:35:26 +0100 Message-ID: References: <87d0bfrxr1.fsf@gnu.org> <87tv4qjy06.fsf@ambrevar.xyz> <875zh6rm5h.fsf@ambrevar.xyz> <87lfq1q7ea.fsf@ambrevar.xyz> <87zhefq0ih.fsf@ambrevar.xyz> <20200124215645.dalemg5qbkpai37m@n0> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:35365) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivnh9-0005Wb-By for guix-devel@gnu.org; Sun, 26 Jan 2020 14:35:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ivnh8-0002Cp-5L for guix-devel@gnu.org; Sun, 26 Jan 2020 14:35:43 -0500 Received: from mail-qk1-x72d.google.com ([2607:f8b0:4864:20::72d]:35186) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ivnh8-0002AS-0a for guix-devel@gnu.org; Sun, 26 Jan 2020 14:35:42 -0500 Received: by mail-qk1-x72d.google.com with SMTP id q15so1175738qki.2 for ; Sun, 26 Jan 2020 11:35:40 -0800 (PST) In-Reply-To: <20200124215645.dalemg5qbkpai37m@n0> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: ison Cc: Guix Devel Hi, On Fri, 24 Jan 2020 at 23:06, ison 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