Re: A plan for parameterized packages

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@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’.