Re: Parameterized packages

[zimoun <zimon.toutoune@gmail.com>]

Hi Pierre,

On Wed, 22 Jan 2020 at 10:54, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> zimoun <zimon.toutoune@gmail.com> 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