Re: Parameterized packages

[Pierre Neidhardt <mail@ambrevar.xyz>]

[-- Attachment #1: Type: text/plain, Size: 6182 bytes --]

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

> What is the final aim to have parametrized packages?
> What does it mean "parametrized"?

Easy and composable customization of packages.

> Does it mean extend the transformation options as Ludo described [2].

I think you forgot this reference.  If you meant "like Ludo described in
the original post" I'd say yes, more or less that.

> Could you define what do you mean by "parameters"?
> Sorry to be slow but I am not clear about what we are talking about
> precisely. :-)

No problem.  "Parameters" is a term Ludo came up with, I believe.  We
can always change the naming later.

In my understanding, a parameter is a "first class, globally defined
object -- that comes with a description and a type -- which value can be
used as condition in a package to modify its output.  A package may rely
on multiple parameters to modify its output."

> 1. Because the initial Ludo's message was about glic-locale which is
> somehow an input.

Yes, but in my opinion the example just happened to be an input
modification, it does not have to be.  Gentoo USE flags don't only
change the dependencies, they also change the compilation options, etc.

> 2. The thread spoke also about flags à la Gentoo USE flags.

Indeed, they are essentially the same, but recent discussions are
leading towards limiting Guix parameters a bit more to avoid
a combinatorial explosion in the maintenance complexity.

> 3. Other messages were about set X or Wayland or no-X for this or that package.

Just like Gentoo "X" USE flag I think.

> 4. Another were about change the toolchain of the build systems.
> etc.

In my opinion, we don't need to change anything in the build system.

The point is that parameters can be used anywhere in the package
definition, and thus it can change #:arguments fields like #:python to
customize the python builder.

> All are "parameters". :-)
>
> The solution of 1. and 4. seems to be able to re-write all the implicit inputs.

As Ison mentioned, this might not be reasonable because it might just
break too often.  A better approach could be to only customize the
direct inputs (and build system options).

> The solution of 2. and 3. seems to write, as Ludo mentioned:
>
> --8<---------------cut here---------------start------------->8---
> (define (make-me-a-package option1 option2)
>     (package
>       …))
> --8<---------------cut here---------------end--------------->8---

The ellipsis is a bit vague here.  What is this trying to do?

> Well, could you clarify what do you have in mind about "parameters"?
> Just to stay on the wavelength and keep focus. :-)

OK, I'll try with one full example:

--8<---------------cut here---------------start------------->8---
(define-public you-get
  (package
    (name "you-get")
    (version "0.4.1355")
    (PARAMETERS VIDEO-PLAYER PYTHON-VERSION WITH-FFMPEG)
    (source (origin
              (method git-fetch)
              (uri (git-reference
                    (url "https://github.com/soimort/you-get.git")
                    (commit (string-append "v" version))))
              (file-name (git-file-name name version))
              (sha256
               (base32
                "0xq7z04hvw3b3npiahlpzhbxsjvam9n9dynplyrkn84dx6k9ajbj"))))
    (build-system python-build-system)
    (inputs
     `(("PLAYER" ,(DEREF-PARAM VIDEO-PLAYER))
       ,@(IF (DEREF-PARAM WITH-FFMPEG)
             ;; FOR MULTI-PART AND >=1080P VIDEOS
             `("FFMPEG" ,FFMPEG)
             '())))             
    (arguments
     `(#:PYTHON ,(DEREF-PARAM PYTHON-VERSION)
       #:phases
       (modify-phases %standard-phases
         ,(WHEN (DEREF-PARAM WITH-FFMPEG)
            (add-after 'unpack 'qualify-input-references
              ;; Explicitly invoke the input ffmpeg, instead of whichever one
              ;; happens to be in the user's $PATH at run time.
              (lambda* (#:key inputs #:allow-other-keys)
                (let ((ffmpeg (string-append (assoc-ref inputs "ffmpeg")
                                             "/bin/ffmpeg")))
                  (substitute* "src/you_get/processor/ffmpeg.py"
                    ;; Don't blindly replace all occurrences of ‘'ffmpeg'’: the
                    ;; same string is also used when sniffing ffmpeg's output.
                    (("(FFMPEG == |\\()'ffmpeg'" _ prefix)
                     (string-append prefix "'" ffmpeg "'")))
                  #t))))
         (ADD-AFTER 'UNPACK 'TWEAK-PLAYER-SETTINGS
           (LAMBDA* (#:KEY INPUTS #:ALLOW-OTHER-KEYS)
             (MATCH ,(DEREF-PARAM VIDEO-PLAYER)
               (VLC
                ;; DO SOMETHING WITH VLC.
                )
               (MPV
                ;; DO SOMETHING WITH MPV.
                )
               (_
                ;; ERROR OUT?
                )))))
       #:tests? #f))                    ; XXX some tests need Internet access
    (synopsis "Download videos, audio, or images from Web sites")
    (description
     "You-Get is a command-line utility to download media contents (videos,
audio, images) from the Web.  It can use either mpv or vlc for playback.")
    (home-page "https://you-get.org/")
    (license license:expat)))
--8<---------------cut here---------------end--------------->8---

In the above I've highlighted the changes in uppercase.

On line (PARAMETERS ...) I've declared which parameters I'm going to use
in my package declaration.  Those parameters must be defined globally
somewhere in Guix.

The point of declaring the parameters in advance is that it allows the
user to list all parameters used by a given package.

In the above example, parameters are used for various things:

- To configure the build system, i.e. here to set which python version
  is going to be used to compile the program.

- To make the FFmpeg input optional.

- To let the user choose which video player to use.  This is a popular
  USE flag on Gentoo (maybe with a different name).

Does that make more sense now?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]