Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

daml3-script default package preference #20270

Closed
samuel-williams-da opened this issue Nov 8, 2024 · 1 comment
Closed

daml3-script default package preference #20270

samuel-williams-da opened this issue Nov 8, 2024 · 1 comment
Assignees

Comments

@samuel-williams-da
Copy link
Contributor

samuel-williams-da commented Nov 8, 2024

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 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.

@samuel-williams-da samuel-williams-da self-assigned this Nov 8, 2024
@samuel-williams-da
Copy link
Contributor Author

Discussed as won't do

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant