You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"This would likely be some flag in the daml script binary to provide a file containing the preference (as defined by a list of package ids)
We would ideally align this to the format canton intends to use for participant preference in daml3, if it exists
Omitted for daml3 as timed vetting will likely replace it, but this can still be discussed"
From discussion:
A simply package-id set would be difficult to maintain, as the id's tell you nothing about the package itself
One could support a format that allows comments, but default json does not do this, and we would likely want to use json
We could use a mapping from name to package id, and validate no duplicate names. This would be easy to maintain
Full validation is difficult though, we cannot verify that the set of package ids only contains one package per package name, as its not a given that daml-script will have the dars to all those packages. Note however that the existing package preference feature of daml script does not verify this either.
One could consider a canton endpoint that gives all know package-ids with their names to resolve this issue.
Paul suggested making this a "runtime" feature of daml-script, introducing a withPackagePreference : [PackageId] -> Script a -> Script a, and taking the preference as an input (via the script binary flag for json input), but this would make UX difficult for users that provide their own input.
We would also want the IDE-ledger to support this, but this should be trivial.
The text was updated successfully, but these errors were encountered:
From upgrade sheet:
"This would likely be some flag in the daml script binary to provide a file containing the preference (as defined by a list of package ids)
We would ideally align this to the format canton intends to use for participant preference in daml3, if it exists
Omitted for daml3 as timed vetting will likely replace it, but this can still be discussed"
From discussion:
A simply package-id set would be difficult to maintain, as the id's tell you nothing about the package itself
One could support a format that allows comments, but default
json
does not do this, and we would likely want to use jsonWe could use a mapping from name to package id, and validate no duplicate names. This would be easy to maintain
Full validation is difficult though, we cannot verify that the set of package ids only contains one package per package name, as its not a given that daml-script will have the dars to all those packages. Note however that the existing package preference feature of daml script does not verify this either.
One could consider a canton endpoint that gives all know package-ids with their names to resolve this issue.
Paul suggested making this a "runtime" feature of daml-script, introducing a
withPackagePreference : [PackageId] -> Script a -> Script a
, and taking the preference as an input (via the script binary flag for json input), but this would make UX difficult for users that provide their own input.We would also want the IDE-ledger to support this, but this should be trivial.
The text was updated successfully, but these errors were encountered: