zimoun <zimon.toutoune@gmail.com> writes:

> I do not understand what you do mean by "does not compose".
>
>
> 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).

Instead, if you'd inherit you'd always overwrite the changes without the
user noticing.  This removes a lot of control.

> --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.

> i.e., no mess with global parameters.

I think there is a misunderstanding, there is no "mess with global
parameters".

Tobias suggestion was to declare the parameters (name, doc and type)
globally, just like we declare record globally.

> 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.

> 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
works.  Of course the package parameters will have to be tested on
update of the package definition.  From the user's perspective, the
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?

-- 
Pierre Neidhardt
https://ambrevar.xyz/