Hello,
I was experimenting with the new string interpolation feature and noticed that I cannot build a project that has module prefixes with variables from environment. Instead it tries to ready that key as a complete string. But it works in dependency is left as variable but the correct package name in the module prefix.
There are also a similar problem in the multi package IDE support feature, where it cannot find process the daml.yaml file as long as any variable is present. Examples:
- On setting an output directory for the build
- Dependencies and data dependencies
- sdk-version, app name and version
Finally, there is also an issue with the IDE support where if the multi-package,yaml file is not on the root of the project, the feature is not functional.
Example
sdk-version: 2.9.3
name: ${APP_NAME}
source: daml
version: ${APP_VERSION}
...
data-dependencies:
- ${DEPENDENCY_NAME_AND_VERSION}.dar
module-prefixes:
${DEPENDENCY_NAME_AND_VERSION}: Dependency
...
build-options:
- --output=${APP_NAME}-${APP_VERSION}.dar
1 Like
Hi David, thanks for the feedback!
To address your specific points:
Variable interpolation on module prefixes
You are correct that this is not currently supported, the variable interpolation affects all string level fields within the daml.yaml, and given that module-prefixes is a map, the keys of that map aren’t affected. We’ll take this into account and push out a fix.
Multi-package IDE Environment Variables
How are your variables defined? Do they exist in the shell before running daml studio? When I use export MY_VAR="something" then run daml studio in the same shell, the interpolation succeeds.
Note that daml studio does not currently handle direnv, so if your environment setup is triggered by that, you’ll need to run daml studio within that shell every time it is re-opened.
Non-root multi-package.yaml
We do not currently support searching for the multi-package.yaml I’m afraid, this feature was slated for a later version (which is one of the reasons why multi-ide is initial access). If you want the contents of your multi-package.yaml to exist elsewhere in the project before this feature is added, you can use a proxy multi-package.yaml at the root of your project that simply points to your main file via the projects: field.
I’ll take a look at fixing the above issues for a future update, and let you know here once they’re ready.
2 Likes
Hello Samuel,
On the topic
Multi-package IDE Environment Variables
The way that I set up the env variables is trough vs code settings where I source a shell script into the integrated terminal so that they are brought into context, like so:
"terminal.integrated.profiles.osx": {
"zsh": {
"path": "/bin/zsh",
"args": ["-c", "source set_env_vars.sh && exec zsh -i"],
},
"bash": {
"path": "/bin/bash",
"args": ["-c", "source set_env_vars.sh && exec bash -i"],
},
}
And this is the terminal prompt for trying to build via multi-package and standalone:
➜ echo $DAML_SDK_VERSION
2.9.3
➜ daml build --all
Running multi-package build of all packages in my-project.
2024-08-20 08:52:53.88 [INFO] [multi-package build]
Building my-project/package/my-project-interface
daml: daml.yaml is an invalid YAML file
context: Determining SDK version and path.
details:
path: my-project/package/my-project-interface/daml.yaml
internal: Aeson exception:
Couldn't find environment variable DAML_SDK_VERSION in value ${DAML_SDK_VERSION}
File: my-project/package/my-project-interface
Hidden: no
Range: 1:1-2:1
Source: compiler
Severity: DsError
Message:
Failed to build package at my-project/package/my-project-interface.
CallStack (from HasCallStack):
error, called at compiler/damlc/lib/DA/Cli/Damlc.hs:1196:44 in compilerZSdamlcZSdamlc-lib:DA.Cli.Damlc
damlc: Error when running Shake build system:
BadDependency "BuildMulti"
➜ cd package/my-project-interface
➜ daml build
Running multi-package build of my-project-interface.
2024-08-20 08:53:32.60 [INFO] [multi-package build]
Building my-project/package/my-project-interface
2024-08-20 08:53:35.19 [INFO] [build]
Compiling my-project-interface to a DAR.
2024-08-20 08:53:35.80 [INFO] [build]
Created my-project/build/my-project-interface-0.0.1.dar
Regarding the other topics I appreciate your response and I look forward to the fixes. Thank you.
Could you try switching your variable name from DAML_SDK_VERSION to something else? We use this exact variable name internally, so it may be colliding. I’ll make a note to warn about this if that’s the case.
As for your VSCode setup, this appears to just be for the terminal, and the terminal isn’t what runs the extension. This could also explain why the variables aren’t seen by VSCode. You may be able to use direnv, I’ve verified that this VSCode direnv extension works with other extensions (including daml)
1 Like
Hello Samuel, indeed the DAML_SDK_VERSION was clashing when using the daml build --all command. Upon changing it, it worked correctly.
I refactored my strucuture to leverage direnv and with the extension everything works as intended.
Also I’ve confirmed that Daml V2.9.4 fixes the var yaml key issue as well.
Thank you for your assistance.
Great! Happy to help 
I’ll have a look at improving the messaging around DAML_SDK_VERSION