From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: Parameterized packages Date: Wed, 22 Jan 2020 13:23:26 +0100 Message-ID: References: <8736ldq74z.fsf@netris.org> <20190719202906.lbanx5puk7t6q4cr@cf0> <87a7753boq.fsf@ambrevar.xyz> <87h813wah0.fsf@gnu.org> <87v9piut40.fsf@ambrevar.xyz> <87o8v5ukgb.fsf@ambrevar.xyz> <87d0blhr9s.fsf@ambrevar.xyz> <20200116190644.uytvzvypuvdwh2iq@n0> <87d0bfrxr1.fsf@gnu.org> <87tv4qjy06.fsf@ambrevar.xyz> <875zh6rm5h.fsf@ambrevar.xyz> <87lfq1q7ea.fsf@ambrevar.xyz> <87zhefq0ih.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:44345) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuF2t-0007so-GM for guix-devel@gnu.org; Wed, 22 Jan 2020 07:23:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuF2r-0006mf-L9 for guix-devel@gnu.org; Wed, 22 Jan 2020 07:23:43 -0500 In-Reply-To: <87zhefq0ih.fsf@ambrevar.xyz> 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: Pierre Neidhardt Cc: Guix Devel Hi Pierre, On Wed, 22 Jan 2020 at 10:54, Pierre Neidhardt wrote: > zimoun writes: > > To me, a package is: > > "./configure && make && make check && make install" > > so I understand why tweak the flags used by "./configure", for example > > change "--with-vlc=" from the default 0 to the tuned 1. Or use another > > compiling toolchain. > > I understand also these flags could require different inputs. > > If we reuse your example, a package may very well have --with-vlc and > --with-mpv. > > Those flags conflict, so the package definition must know about the > corresponding "package parameters" at the same time to raise the > appropriate error (or choose The Right Option automatically). It is the job to './configure' to detect conflicting parameters and not the job of the package definition, IMHO. The well-known: crap in, crap out! :-) > Instead, if you'd inherit you'd always overwrite the changes without the > user noticing. This removes a lot of control. Yes, I agree with the current implementation. That's why I wrote: ;-) << And again from my understanding, this is more or less cover by 'inherit'. Or some macrology should be improved in 'package/inherit' or in 'records.scm', i.e., something more fine grained when inheriting. >> > > --8<---------------cut here---------------start------------->8--- > > (define (make-you-get VIDEO-PLAYER PYTHON-VERSION WITH-FFMPEG) > > (package > > (inherit you-get > > #:add-inputs > > `(("PLAYER" ,VIDEO-PLAYER)) > > ,@(IF WITH-FFMPEG) > > ;; FOR MULTI-PART AND >=1080P VIDEOS > > `("FFMPEG" ,FFMPEG) > > #:replace-arguments ... > > #:add-phase ... > > '()))) > > > > (define-public you-get-vlc (make-you-get 'vlc)) > > --8<---------------cut here---------------end--------------->8--- > > > > > > Something like that. And everything is more controlled, > > What you propose here is essentially the same as what I propose, the > difference is that you wrapped it around `make-you-get` instead of > declaring the parameters inside as a field. The big differences are: 1. the base package is untouched 2. the arguments are locally defined 3. everything is explicit So less surprises IMHO. > > i.e., no mess with global parameters. > > I think there is a misunderstanding, there is no "mess with global > parameters". Where should be defined what you called VIDEO-PLAYER? the one in ' (PARAMETERS VIDEO-PLAYER PYTHON-VERSION WITH-FFMPEG)'. Because the symbol needs to be defined somewhere, right? > Tobias suggestion was to declare the parameters (name, doc and type) > globally, just like we declare record globally. It will end with a big mess because there is almost as many "parameters" as packages. And 'parameter' means somehow 'symbol', isn't it? > > What you want to do is: add/remove/replace inputs/arguments so > > #:add-inputs, #:remove-native-inputs, etc. > > Not just that, that's the point: we want the possibility to modify > anything, in particular what's inside #:arguments. I am suggesting the same thing. :-) But instead I am suggesting to pass the modifications 'arguments' via inheritance mechanism. > > Hum? but months later your system is broken... so I am not convinced > > it is powerful. :-) > > > > It is broken because composing complex system is an hard task. Typing > > helps a bit to detect error at compile time (in this case at building > > package time) but run-time errors will still remain and it will be > > hard time to find them. > > Why would it be broken after months? Packagers do the work once and it I do not know but it is what Gentoo users are saying. Well, I know a awesome guy wearing psychadelic T-shirt and former Gentoo user that explained me that IRL. ;-) > works. Of course the package parameters will have to be tested on > update of the package definition. From the user's perspective, the This adds a lot of workload to packagers, IMHO. > worst case scenario is that a formerly support parameter goes > unsupported for a given package, in which case we show a warning. > > What do you think? Well, I am wanting the same thing: be able to modify the 'arguments' field but I am not convinced by the design you are proposing because I have the feeling that with such design then mess is coming. :-) Cheers, simon