From mboxrd@z Thu Jan 1 00:00:00 1970 From: ison Subject: Re: Parameterized packages Date: Fri, 24 Jan 2020 14:56:45 -0700 Message-ID: <20200124215645.dalemg5qbkpai37m@n0> References: <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=us-ascii Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:36966) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iv75j-0004fg-Lt for guix-devel@gnu.org; Fri, 24 Jan 2020 17:06:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iv75i-0006rr-6Q for guix-devel@gnu.org; Fri, 24 Jan 2020 17:06:15 -0500 Received: from cock.li ([2a06:1700:0:b::c0cc]:52116) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iv75g-0006eT-Qm for guix-devel@gnu.org; Fri, 24 Jan 2020 17:06:13 -0500 Content-Disposition: inline In-Reply-To: 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: zimoun Cc: guix-devel@gnu.org On Wed, Jan 22, 2020 at 01:23:26PM +0100, zimoun wrote: > > > --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. 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. I hope I'm not missing something here, but this is how I was reading the conversation. 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? It almost seems like achieving that would require a parameters field in the package anyway. 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.