[PATCH 0/1] guix: pack: add --entry-point-argument option

> * guix/scripts/pack.scm: add support for parameters in entry-point

> (entry-point-argument-spec-option-parser): add function to parse --entry-point-argument

> (docker-image): Add function (form_entry_point) to handle --entry-point

> vs --entry-point-argument merging

> (docker-image): change call to (build-docker-image) to use (form-entry-point)

> (%default-options): add dafault for --entry-point-argument option

> (%docker-format-options): parser for --entry-point-argument

> (show-docker-format-options): help for --docker-format-options

> (show-docker-format-options/detailed): detailed help for --docker-format-options

> (%options): add flag for --help-docker-format and add parser for --docker-format-options

> (extra-options): add entry-point-argument option

> (guix.texi): add documentation

> +@cindex entry point arguments, for docker images

> +@item --entry-point-argument=@var{command}

> +@itemx -A @var{command}

> +Use @var{command} as an argument to @dfn{entry point} of the resulting pack.

> +This option is only valid in conjunction with @code{--entry-point} and can

> +appear multiple times on the command line.

> +@example

> +guix pack -f docker --entry-point=bin/guile --entry-point-argument="--help" guile

> +@end example

> +(define (entry-point-argument-spec-option-parser opt name arg result)

> + "A SRFI-37 opion parser for the --entry-point-argument option. The spec

> +takes multiple occurances. The entries are used in the exec form for the

> +docker entry-point. The values are used as parameters in conjunction with

> +the --entry-point option which is used as the first value in the exec form."

> + (let ((entry-point-argument (assoc-ref result 'entry-point-argument)))

> + (alist-cons 'entry-point-argument

> + (append entry-point-argument (list arg))

> + (alist-delete 'entry-point-argument result eq?))))

> + (define (form-entry-point

> + prefix entry-point

> + entry-point-argument)

> + ;; construct entry-point parameter for build-docker-image

> + ;; the first entry is constructed by prefixing the entry-point

> + ;; with the supplied index subsequent entries are taken from

> + ;; the --entry-point-argument options

> + (cond

> + (entry-point

> + (cons*

> + (string-append prefix "/" entry-point)

> + entry-point-argument)

> + )

> + ('()))) ;empty list returned if no conditions are met

> +

> + (let-keywords '#$extra-options #f ((entry-point-argument #f))

> + (setenv "PATH" #+(file-append archiver "/bin"))

> +

> + (build-docker-image #$output

> + (map store-info-item

> + (call-with-input-file "profile"

> + read-reference-graph))

> + #$profile

> + #:repository (manifest->friendly-name

> + (profile-manifest #$profile))

> + #:database #+database

> + #:system (or #$target %host-type)

> + #:environment environment

> + #:entry-point (form-entry-point

> + #$profile

> + #$entry-point

> + entry-point-argument)

> @@ -1346,6 +1375,7 @@ (define %default-options

> (debug . 0)

> (verbosity . 1)

> (symlinks . ())

> + (entry-point-argument . ())

> +(define %docker-format-options

> + (list (option '(#\A "entry-point-argument") #t #f

> + entry-point-argument-spec-option-parser)))

> +

> +(define (show-docker-format-options)

> + (display (G_ "

> + --help-docker-format

> + list options specific to the DOCKER format")))

> +

> +(define (show-docker-format-options/detailed)

> + (display (G_ "

> + -A, --entry-point-argument=COMMAND/PARAMETER

> + Value(s) to use for the Docker EntryPoint arguments.

> + Multiple instances are accepted. This is only valid

> + in conjunction with the --entry-point option."))

> + (newline)

> + (exit 0))

> +

> (define %options

> ;; Specifications of the command-line options.

> (cons* (option '(#\h "help") #f #f

> @@ -1508,8 +1557,13 @@ (define %options

> (lambda args

> (show-rpm-format-options/detailed)))

>

> + (option '("help-docker-format") #f #f

> + (lambda args

> + (show-docker-format-options/detailed)))

> +

> (append %deb-format-options

> %rpm-format-options

> + %docker-format-options

> @@ -1528,6 +1582,7 @@ (define (show-help)

> (newline)

> (show-deb-format-options)

> (show-rpm-format-options)

> + (show-docker-format-options)

> @@ -1696,6 +1751,8 @@ (define-command (guix-pack . args)

> (process-file-arg opts 'preun-file)

> #:postun-file

> (process-file-arg opts 'postun-file)))

> + ('docker

> + (list #:entry-point-argument (assoc-ref opts 'entry-point-argument)))

>> +(define (entry-point-argument-spec-option-parser opt name arg result)

>> + "A SRFI-37 opion parser for the --entry-point-argument option. The spec

>> +takes multiple occurances. The entries are used in the exec form for the

>> +docker entry-point. The values are used as parameters in conjunction with

>> +the --entry-point option which is used as the first value in the exec form."

>> + (let ((entry-point-argument (assoc-ref result 'entry-point-argument)))

>> + (alist-cons 'entry-point-argument

>> + (append entry-point-argument (list arg))

>> + (alist-delete 'entry-point-argument result eq?))))

>

> I would just keep a regular option parser that does:

>

> (alist-cons 'entry-point-argument arg result)

>

> Later on, we’d collect all these arguments:

>

> (reverse

> (filter-map (match-lambda

> (('entry-point-argument . arg) arg)

> (_ #f))

> opts))

>

> I think this would be a bit clearer; this is what ‘guix repl’ does, for

> instance.

> This can be omitted if you take the approach suggested above, with one

> ‘entry-point-argument’ pair per argument.

> This would become #:entry-point-arguments (plural), with the

> ‘filter-map’ trick shown above.

> Just to be sure to understand, the command-line could list several

> --entry-point-argument options, right?

> Well, since the order of the various command-line arguments might

> matter, and since a ’reverse’ is suggested, and since all the Guix

> command-lines do not behave the same way – for instance “guix package”

> processes command-line argument from right to left; see #43585 or #50473

> [1,2]; anyway :-) – I would suggest to add a sentence in the

> documentation (manual) that the command-line arguments are parsed from

> left to right.

> > Well, since the order of the various command-line arguments might

> > matter, and since a ’reverse’ is suggested, and since all the Guix

> > command-lines do not behave the same way – for instance “guix package”

> > processes command-line argument from right to left; see #43585 or #50473

> > [1,2]; anyway :-) – I would suggest to add a sentence in the

> > documentation (manual) that the command-line arguments are parsed from

> > left to right.

>

> No: the ‘reverse’ puts them back in the right order (because

> ‘args-fold*’ traverses the option list from left to right and thus

> conses the result in reverse order.)

> I would like to merge 62153. After 64173 will be merge, merging 62153

> is not possible without conflict resolving with Git.

>

> 64173 introduces ‘%docker-format-options’ variable. With this variable

> it's possible in 62153 to replace ‘--image-type=docker-layered’ with

> ‘--docker-layers=N’ option, where:

>

> if ‘N’ is zero, then use current non layered format

> if ‘N’ is bigger than zero, then use layered format

> Number of layers specification is nice to have, because Docker layers

> are limited. So if user would like to modify a Docker image by adding

> more layers on top, then hacks like squashing layers are not required.

> Also, it will be possible to delete code which builds non layered Docker

> image without deprecating command line options.

> Apologies for not replying earlier. I occasionally get reminded of the

> fact that building single-layer images is a problem, but only now did I

> take the time to look more closely at the latest version of these

> patches.

>

> Oleg Pykhalov <go.wigust@gmail.com> skribis:

>

>> I would like to merge 62153. After 64173 will be merge, merging 62153

>> is not possible without conflict resolving with Git.

>>

>> 64173 introduces ‘%docker-format-options’ variable. With this variable

>> it's possible in 62153 to replace ‘--image-type=docker-layered’ with

>> ‘--docker-layers=N’ option, where:

>>

>> if ‘N’ is zero, then use current non layered format

>> if ‘N’ is bigger than zero, then use layered format

>

> OK we should do that. However, the original submitter of #64173

> apparently dropped the ball as we were approaching the final version.

>

> Would you like to adopt it and submit/push a version that incorporates

> the latest comments?

>

> Alternatively, we could do the opposite: merge the Docker layer patches

> first, and then rebase the ‘%docker-format-options’ patch, after which

> we could add the ‘--docker-layers’ option.

>

> What’s your preference?