Originally created by @z-jxy on GitHub (May 24, 2025).
Version: Pkl 0.28.2 (Windows 10.0, native)
Pkl fails to find the env: resource on Windows
➜ pkl eval .\tests\pkl\allowed-resources.pkl
ΓÇôΓÇô Pkl Error ΓÇôΓÇô
Cannot find resource `env:PATH`.
1 | path = read("env:PATH")
^^^^^^^^^^^^^^^^
at allowed-resources#path (file:///C:/Users/user/tests/pkl/allowed-resources.pkl, line 1)
106 | text = renderer.renderDocument(value)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
at pkl.base#Module.output.text (https://github.com/apple/pkl/blob/0.28.2/stdlib/base.pkl#L106)
Originally created by @z-jxy on GitHub (May 24, 2025).
Version: `Pkl 0.28.2 (Windows 10.0, native)`
Pkl fails to find the `env:` resource on Windows
```
➜ pkl eval .\tests\pkl\allowed-resources.pkl
ΓÇôΓÇô Pkl Error ΓÇôΓÇô
Cannot find resource `env:PATH`.
1 | path = read("env:PATH")
^^^^^^^^^^^^^^^^
at allowed-resources#path (file:///C:/Users/user/tests/pkl/allowed-resources.pkl, line 1)
106 | text = renderer.renderDocument(value)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
at pkl.base#Module.output.text (https://github.com/apple/pkl/blob/0.28.2/stdlib/base.pkl#L106)
```
This error is telling you that the PATH env var is not set.
You can see all the env vars that are available with a globbed read, e.g. read*("env:**").
If you want to handle the case where the path is not set, you can do read?("env:PATH"), which gives you a nullable value.
@bioball commented on GitHub (Jul 29, 2025):
This error is telling you that the `PATH` env var is not set.
You can see all the env vars that are available with a globbed read, e.g. `read*("env:**")`.
If you want to handle the case where the path is not set, you can do `read?("env:PATH")`, which gives you a nullable value.
You can see all the env vars that are available with a globbed read, e.g. read*("env:**").
If you want to handle the case where the path is not set, you can do read?("env:PATH"), which gives you a nullable value.
Didn't know this was possible, thanks for this!
I worded this issue poorly, my problem was that it's not finding the PATH environment variable specifically.
After updating the file to use read*("env:**"), I realized the reason it doesn't work is because its mapped to env:Path when I was expecting env:PATH. (environment variables are case-insensitive on Windows)
This behavior is technically correct because the variable is Path canonically, but this causes my file to be platform dependent (unless there's a way around this that I'm not aware of).
Ideally, I would want read("env:PATH") to work on both Linux and Windows, but I don't think it would make sense to support this:
Case is very specific
Solution feels wrong in general
Requires either mapping the variable into both env:Path and env:PATH or just env:PATH (maybe there's another way?)
Mapping into both seems wasteful
If it only mapped to env:PATH, env:Path would no longer work, when it should
Language bindings would have to be aware of this
Brings up the question of why other environment variables don't behave the same way
I think a better solution would be if Pkl provided a way to access common environment variables across supported platforms (i.e., PATH, HOME, OS). Maybe this could be moved to a discussion? I think there are good uses cases for this
@z-jxy commented on GitHub (Jul 29, 2025):
> You can see all the env vars that are available with a globbed read, e.g. `read*("env:**")`.
>
> If you want to handle the case where the path is not set, you can do `read?("env:PATH")`, which gives you a nullable value.
Didn't know this was possible, thanks for this!
I worded this issue poorly, my problem was that it's not finding the `PATH` environment variable specifically.
After updating the file to use `read*("env:**")`, I realized the reason it doesn't work is because its mapped to `env:Path` when I was expecting `env:PATH`. (environment variables are case-insensitive on Windows)
This behavior is technically correct because the variable is `Path` canonically, but this causes my file to be platform dependent (unless there's a way around this that I'm not aware of).
Ideally, I would want `read("env:PATH")` to work on both Linux and Windows, but I don't think it would make sense to support this:
- Case is very specific
- Solution feels wrong in general
- Requires either mapping the variable into both `env:Path` and `env:PATH` or just `env:PATH` (maybe there's another way?)
- Mapping into both seems wasteful
- If it only mapped to `env:PATH`, `env:Path` would no longer work, when it should
- Language bindings would have to be aware of this
- Brings up the question of why other environment variables don't behave the same way
I think a better solution would be if Pkl provided a way to access common environment variables across supported platforms (i.e., PATH, HOME, OS). Maybe this could be moved to a discussion? I think there are good uses cases for this
Hm, that's worth thinking about. Pkl already has the pkl:platform stdlib module, which provides many details, by the way.
You can implement a platform-specific read like so:
Feel free to create a new discussion about extending the Platform class.
@bioball commented on GitHub (Jul 29, 2025):
Hm, that's worth thinking about. Pkl already has the `pkl:platform` stdlib module, which provides many details, by the way.
You can implement a platform-specific read like so:
```pkl
import "pkl:platform"
pathEnv: String? =
if (platform.current.operatingSystem.name == "Windows")
read?("env:Path")
else
read?("env:PATH")
```
Feel free to create a new discussion about extending the `Platform` class.
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 @z-jxy on GitHub (May 24, 2025).
Version:
Pkl 0.28.2 (Windows 10.0, native)Pkl fails to find the
env:resource on Windows@bioball commented on GitHub (Jul 29, 2025):
This error is telling you that the
PATHenv var is not set.You can see all the env vars that are available with a globbed read, e.g.
read*("env:**").If you want to handle the case where the path is not set, you can do
read?("env:PATH"), which gives you a nullable value.@z-jxy commented on GitHub (Jul 29, 2025):
Didn't know this was possible, thanks for this!
I worded this issue poorly, my problem was that it's not finding the
PATHenvironment variable specifically.After updating the file to use
read*("env:**"), I realized the reason it doesn't work is because its mapped toenv:Pathwhen I was expectingenv:PATH. (environment variables are case-insensitive on Windows)This behavior is technically correct because the variable is
Pathcanonically, but this causes my file to be platform dependent (unless there's a way around this that I'm not aware of).Ideally, I would want
read("env:PATH")to work on both Linux and Windows, but I don't think it would make sense to support this:env:Pathandenv:PATHor justenv:PATH(maybe there's another way?)env:PATH,env:Pathwould no longer work, when it shouldI think a better solution would be if Pkl provided a way to access common environment variables across supported platforms (i.e., PATH, HOME, OS). Maybe this could be moved to a discussion? I think there are good uses cases for this
@bioball commented on GitHub (Jul 29, 2025):
Hm, that's worth thinking about. Pkl already has the
pkl:platformstdlib module, which provides many details, by the way.You can implement a platform-specific read like so:
Feel free to create a new discussion about extending the
Platformclass.@z-jxy commented on GitHub (Jul 29, 2025):
Ahh I didn't know about the platform module. That solves my issue. Thanks again!