Re: Parameterized packages

[ison]

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.