Can't read env: resource on Windows #310

Closed
opened 2025-12-30 01:23:26 +01:00 by adam · 4 comments
Owner

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) ```
adam closed this issue 2025-12-30 01:23:27 +01:00
Author
Owner

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

@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.
Author
Owner

@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

@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
Author
Owner

@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:

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.

@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.
Author
Owner

@z-jxy commented on GitHub (Jul 29, 2025):

Ahh I didn't know about the platform module. That solves my issue. Thanks again!

@z-jxy commented on GitHub (Jul 29, 2025): Ahh I didn't know about the platform module. That solves my issue. Thanks again!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pkl#310