Hi, zimoun <zimon.touto...@gmail.com> skribis:
>> To me the requirements for package parameters are: >> >> 1. it must be possible to discover them and choose them from the UI; >> >> 2. they must contain on-line internationalized documentation such that >> the UI can list a package’s parameters and their type; > > Except ’boolean’, which kind of type do you have in mind? Aside that > you did not find examples of packages requiring parameters. ;-) Another example would be enumerated types. >> 3. the chosen parameters when installing a package in a profile must >> be preserved; > > You mean track the parameters with ’properties’ in <profile>/manifest, > right? Yup! >> 4. it must be possible to enumerate all the possible values of a >> parameter, and thus to build the Cartesian product of all the >> possible parameter combinations of a package (or of a package >> graph!), so we can test those combinations as much as possible. > > The values of the option are therefore known at package time, right? > However, this implies restricted possibility for the type, right? The <package-parameter> record has to specify a type, and the type must have a finite universe. So there cannot be an “integer” type, for instance, but there can be “integer between 10 and 42”. >> +(define (evaluate-parameter-specs specs proc) >> + "Parse SPECS, a list of strings like \"bitlbee=purple=true\", and return a >> +list of spec/procedure pairs, where (PROC PACKAGE PARAMETER VALUE) is called >> +to return the replacement package. Raise an error if an element of SPECS >> uses >> +invalid syntax, or if a package it refers to could not be found." >> + (map (lambda (spec) >> + (match (string-tokenize spec %not-equal) >> + ((spec name value) >> + (define (replace old) >> + (proc old name value)) >> + >> + (cons spec replace)) >> + (_ >> + (raise >> + (formatted-message >> + (G_ "invalid package parameter specification: ~s") >> + spec))))) >> + specs)) > > Here ’proc’ could be anything, right? But then… > >> +(define (transform-package-parameters replacement-specs) >> + "Return a procedure that, when passed a package, replaces its direct >> +dependencies according to REPLACEMENT-SPECS. REPLACEMENT-SPECS is a list of >> +strings like \"guile-next=stable-3.0\" meaning that packages are built using >> +'guile-next' from the latest commit on its 'stable-3.0' branch." >> + (define (replace old name value) >> + (set-package-parameter-value old name value)) >> + >> + (let* ((replacements (evaluate-parameter-specs replacement-specs >> + replace)) >> + (rewrite (package-input-rewriting/spec replacements))) >> + (lambda (obj) >> + (if (package? obj) >> + (rewrite obj) >> + obj)))) > > … it is ’set-package-parameter-value’. It is not clear in my mind. Yes I could have used ‘set-package-parameter-value’ directly instead of adding this ‘proc’ parameter; it would have been more readable I guess! Thanks, Ludo’.