Support for dynamic expressions in import()

[naxty]

I have been playing around quite a lot with the pkl project and try to understands it's limitations. Right now, I'm building schema reflection tool that requires dynamic imports. The idea is to provide a prop to a schema on runtime and then do further processing with it. Unfortunately, I have realized that the ImportExpr only allows StringConstant. What is the reasoning behind this?

module importExpr

/// Package path
package: String = read("prop:Package")

schemaImports = import*("\(package)/*pkl")

output {
    value = schemaImports.toMap().toDynamic()
}

Output

❯ pkl eval importExpr.pkl -p Package=test2
–– Pkl Error ––
String constant cannot have interpolated values.

6 | schemaImports = import*("\(package)/*pkl")
                             ^^
at importExpr (file:///Users/stheno/git/pel/formae/pkg/plugin/schema/test/importExpr.pkl, line 6)

Use Case

I want to build a tool that:

• Accepts a package path as a runtime property
• Dynamically imports all .pkl files from that package
• Processes the imported schemas for reflection/code generation

This pattern is common in:

• Schema discovery tools
• Plugin systems
• Code generators that need to enumerate modules
• Configuration tools that load modules based on environment

Current Workaround

There's no clean workaround. The only option is to pre-compute all possible import paths and use conditional logic, which doesn't scale.

Proposed Solution

Allow import() and import*() expressions to accept any expression that evaluates to a string at runtime, not just string literals.

// These should all work:
import(variable)
import("\(path)/module.pkl")
import("\(path)/**.pkl")
import(if (condition) "a.pkl" else "b.pkl")
import(computePath())

Considerations

I understand that static imports enable:

• Static analysis - Build tools can determine dependencies without execution
• IDE support - Navigation, autocomplete, refactoring
• Security - Import paths can be validated at parse time

A reasonable middle ground would be:

• Keep top-level import "..." declarations as string-constant-only (for static analysis)
• Allow import(...) expressions to be dynamic (for runtime flexibility)
• This preserves static analysis for declared imports while enabling dynamic use cases for import expressions.

Questions for Maintainers

1. What were the original design considerations for restricting imports to string constants?
2. Would you be open to a PR that implements dynamic import expressions? I have a finished PR in my repo and happy to submit it against the pkl repo Allow dynamic expressions in import() expressions naxty/pkl#1
3. Are there security concerns with runtime-evaluated import paths that I should be aware of?