Originally created by @Frnd-me on GitHub (Sep 16, 2025).
I'm using the Pkl Java bindings in a runtime system, where Pkl is the basis for a DSL.
For my DSL, I have a standard library, for which it is convenient to add a module like dsl:Something.
The Java bindings support this neatly: internally, the dsl: scheme gets translated to a classpath resource shipped with the runtime build. However, current support within IDEs and the CLI does not enable ergonomic handling of user-defined modules.
It would be very convenient if there were a way to define (globally, for instance, in Pkl settings) the handler for such schemes (for example, pointing to a URL where the same module can be fetched).
As far as I can tell from the documentation, this is currently possible at a project level, but that may not always be desirable; sometimes you want a global setting without needing to create a project.
Currently, the handling of schemes in the IDE plugins and CLI appears to be fairly static.
Full support throughout the toolchain would make user-defined module support more useful.
Proposed solution
Allow defining global scheme handlers in Pkl settings (CLI, IDE, or system-level config).
Ensure that the same scheme resolution works consistently across:
CLI tooling
IDE integrations (VSCode, IntelliJ, etc.)
Runtime bindings (Java, etc.)
This would make user-defined modules a first-class feature in the Pkl ecosystem, improving ergonomics for DSLs and other custom uses of Pkl.
Originally created by @Frnd-me on GitHub (Sep 16, 2025).
I'm using the Pkl Java bindings in a runtime system, where Pkl is the basis for a DSL.
For my DSL, I have a standard library, for which it is convenient to add a module like `dsl:Something`.
The Java bindings support this neatly: internally, the `dsl:` scheme gets translated to a classpath resource shipped with the runtime build. However, current support within IDEs and the CLI does not enable ergonomic handling of user-defined modules.
It would be very convenient if there were a way to define (globally, for instance, in Pkl settings) the handler for such schemes (for example, pointing to a URL where the same module can be fetched).
As far as I can tell from the documentation, this is currently possible at a project level, but that may not always be desirable; sometimes you want a global setting without needing to create a project.
Currently, the handling of schemes in the IDE plugins and CLI appears to be fairly static.
Full support throughout the toolchain would make user-defined module support more useful.
## Proposed solution
- Allow defining global scheme handlers in Pkl settings (CLI, IDE, or system-level config).
- Ensure that the same scheme resolution works consistently across:
- CLI tooling
- IDE integrations (VSCode, IntelliJ, etc.)
- Runtime bindings (Java, etc.)
This would make user-defined modules a first-class feature in the Pkl ecosystem, improving ergonomics for DSLs and other custom uses of Pkl.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Frnd-me on GitHub (Sep 16, 2025).
I'm using the Pkl Java bindings in a runtime system, where Pkl is the basis for a DSL.
For my DSL, I have a standard library, for which it is convenient to add a module like
dsl:Something.The Java bindings support this neatly: internally, the
dsl:scheme gets translated to a classpath resource shipped with the runtime build. However, current support within IDEs and the CLI does not enable ergonomic handling of user-defined modules.It would be very convenient if there were a way to define (globally, for instance, in Pkl settings) the handler for such schemes (for example, pointing to a URL where the same module can be fetched).
As far as I can tell from the documentation, this is currently possible at a project level, but that may not always be desirable; sometimes you want a global setting without needing to create a project.
Currently, the handling of schemes in the IDE plugins and CLI appears to be fairly static.
Full support throughout the toolchain would make user-defined module support more useful.
Proposed solution
This would make user-defined modules a first-class feature in the Pkl ecosystem, improving ergonomics for DSLs and other custom uses of Pkl.