Nix support #76

New Issue

@adrian-gierakowski nope not a duplicate.
My intention was to use apple pkl to add support for nix configuration files such as configuration.nix and flakes to easily assist anyone looking to setup NixOS as a server or personal worksation. #113 speaks of installation of pkl on NixOS.

@alexthotse commented on GitHub (Mar 17, 2024): @adrian-gierakowski nope not a duplicate. My intention was to use apple pkl to add support for nix configuration files such as configuration.nix and flakes to easily assist anyone looking to setup NixOS as a server or personal worksation. #113 speaks of installation of pkl on NixOS.

adam commented

2025-12-30 01:20:28 +01:00

@bioball commented on GitHub (Mar 17, 2024):

Re-opened!

@bioball commented on GitHub (Mar 17, 2024): Re-opened!

adam commented

2025-12-30 01:20:28 +01:00

@izelnakri commented on GitHub (Mar 19, 2024):

Hi @stackoverflow , this is absolutely not a duplicate.

I've been thinking about & need this use-case as well @alexthotse . I think this is where pkl could truly shine for large scale adoption, in addition to all other strong use-cases/migrations like k8s workflows. I would have liked to move my ~/.config/home-manager/home.nix to ~/.config/home-manager/home.pkl as well.

pkl-cli eval command needs to support nix language:

$ jpkl eval -f nix home.pkl

So far based on my investigation, it could provide that as long as eval-ed pkl objects don't have "entries" that are public(maybe "hidden" entries could pass the output render checks). Objects with pkl entries also fail to be converted to json or yaml. A json/yaml can always be converted to pkl and nix however pkl environment will miss the possible pkl type declarations(as it could have for home-manager) during eval runtime unless certain nix renderer is used.

Another option is to build a typed home-manager in pkl and interop will be challenging but earlier we start is better I think. Regardless a nix format is absolutely needed for $ pkl eval -f nix foo.pkl.

I'm still learning/investigating Pkl, I already see Pkl as an improvement to nix, the language overall(not the nix, the store).

@izelnakri commented on GitHub (Mar 19, 2024): Hi @stackoverflow , this is absolutely not a duplicate. I've been thinking about & need this use-case as well @alexthotse . I think this is where pkl could truly shine for large scale adoption, in addition to all other strong use-cases/migrations like k8s workflows. I would have liked to move my `~/.config/home-manager/home.nix` to `~/.config/home-manager/home.pkl` as well. pkl-cli `eval` command needs to support `nix` language: ```bash $ jpkl eval -f nix home.pkl ``` So far based on my investigation, it could provide that as long as eval-ed pkl objects don't have "entries" that are public(maybe "hidden" entries could pass the output render checks). Objects with pkl entries also fail to be converted to json or yaml. A json/yaml can always be converted to pkl and nix however pkl environment will miss the possible pkl type declarations(as it could have for home-manager) during eval runtime unless certain nix renderer is used. Another option is to build a typed home-manager in pkl and interop will be challenging but earlier we start is better I think. Regardless a nix format is absolutely needed for `$ pkl eval -f nix foo.pkl`. I'm still learning/investigating Pkl, I already see `Pkl` as an improvement to `nix`, the language overall(not the nix, the store).

adam commented

2025-12-30 01:20:29 +01:00

@alexthotse commented on GitHub (Mar 19, 2024):

@izelnakri You clearly have a bigger picture as to how Nix and Pkl can coexist with one another. This is what I had envisioned in a nutshell. Thank you for wording it out.

@bioball Appreciate the re-open as this will help bring a new approach to future configuration of systems as a whole.

So the question would be how can we join our efforts to make this a possibility?

@alexthotse commented on GitHub (Mar 19, 2024): @izelnakri You clearly have a bigger picture as to how Nix and Pkl can coexist with one another. This is what I had envisioned in a nutshell. Thank you for wording it out. @bioball Appreciate the re-open as this will help bring a new approach to future configuration of systems as a whole. So the question would be how can we join our efforts to make this a possibility?

adam commented

2025-12-30 01:20:29 +01:00

@adrian-gierakowski commented on GitHub (Mar 19, 2024):

Can a pkl file export a function?

@adrian-gierakowski commented on GitHub (Mar 19, 2024): Can a pkl file export a function?

adam commented

2025-12-30 01:20:29 +01:00

@izelnakri commented on GitHub (Mar 19, 2024):

Can a pkl file export a function?

very good question @adrian-gierakowski & I made it sort of work :) However as far as I know the current language design discourages "one-function-per-file" concept unless its generated.

Pkl modules have a special output object that can have a value definition, this might look like an arbitrary choice but rather it seems to be the convention, internally speaking. Depending on the non-pkl output mode, the relevant parser/generator can/will always read this namespace. Example:

function.pkl:

output {
  value: (n) -> n * 2 // our custom function
}

main.pkl:

my_function = import("function.pkl") // if you want this key ignored by output make it "hidden my_function = import()"

result = my_function.output.value.apply(22)

jpkl eval -f json main.pkl
# json output will be { result: 44 }

@izelnakri commented on GitHub (Mar 19, 2024): > Can a pkl file export a function? very good question @adrian-gierakowski & I made it sort of work :) However as far as I know the current language design discourages "one-function-per-file" concept unless its generated. Pkl modules have a special `output` object that can have a `value` definition, this might look like an arbitrary choice but rather it seems to be the convention, internally speaking. Depending on the non-pkl output mode, the relevant parser/generator can/will always read this namespace. Example: function.pkl: ```pkl output { value: (n) -> n * 2 // our custom function } ``` main.pkl: ```pkl my_function = import("function.pkl") // if you want this key ignored by output make it "hidden my_function = import()" result = my_function.output.value.apply(22) ``` ```bash jpkl eval -f json main.pkl # json output will be { result: 44 } ```

adam commented

2025-12-30 01:20:30 +01:00

@bioball commented on GitHub (Mar 19, 2024):

Functions are internal to Pkl; not exportable.

I don't have any experience working with nix. But: you can write an in-language renderer to turn Pkl into nix.

For example, here is a renderer that writes Pkl -> TOML: https://github.com/apple/pkl-pantry/blob/main/packages/pkl.toml/toml.pkl

@bioball commented on GitHub (Mar 19, 2024): Functions are internal to Pkl; not exportable. I don't have any experience working with nix. But: you can write an _in-language_ renderer to turn Pkl into nix. For example, here is a renderer that writes Pkl -> TOML: https://github.com/apple/pkl-pantry/blob/main/packages/pkl.toml/toml.pkl

adam commented

2025-12-30 01:20:30 +01:00

@holzensp commented on GitHub (Mar 20, 2024):

A nix output format is certainly a reasonable way in, although that could just be a renderer in Pkl (see the TOML renderer). That said, the nix format has a bunch of programming constructs that you'll not get out of Pkl. Doesn't nix tooling also read static formats anywhere? Alternatively, the real support would be got by getting nix to use Pkl as a library, so that it can 'natively' consume .pkl files.

(Edit: As @bioball said; I had choppy internet, so this posted late)

@holzensp commented on GitHub (Mar 20, 2024): A `nix` output format is certainly a reasonable way in, although that could just be a renderer *in* Pkl (see the [TOML renderer](https://github.com/apple/pkl-pantry/blob/main/packages/pkl.toml/toml.pkl)). That said, the `nix` format has a bunch of programming constructs that you'll not get out of Pkl. Doesn't nix tooling also read static formats anywhere? Alternatively, the _real_ support would be got by getting `nix` to use Pkl as a library, so that it can 'natively' consume `.pkl` files. (Edit: As @bioball said; I had choppy internet, so this posted late)

adam commented

2025-12-30 01:20:31 +01:00

@adrian-gierakowski commented on GitHub (Mar 20, 2024):

Nix can import json (and toml) natively so if you generate, say k8s config in pkl you could import it into nix and manipulate further using nix language

but things like configuration.nix or home manager config are usually functions. Not sure how one could use pkl for that and what’s the benefit over just using nix

@adrian-gierakowski commented on GitHub (Mar 20, 2024): Nix can import json (and toml) natively so if you generate, say k8s config in pkl you could import it into nix and manipulate further using nix language but things like configuration.nix or home manager config are usually functions. Not sure how one could use pkl for that and what’s the benefit over just using nix

adam commented

2025-12-30 01:20:31 +01:00

@izelnakri commented on GitHub (Mar 28, 2024):

but things like configuration.nix or home manager config are usually functions. Not sure how one could use pkl for that and what’s the benefit over just using nix

@adrian-gierakowski I think the benefit would be that nix, home-configuration.nix & configuration.nix could use Pkl documentation generator for documentation in the future and perhaps all the typed data structures would be easily debuggable, interactively peeked with $ jpkl repl. Both functions return an expected object and debugging/peeking that returned object before manipulation/development make things very productive including the benefit of being able to debug the imported flakes interactively.

Missing or impartial documentation for data structures has been my biggest DX issue with learning and doing anything advanced with nix/home-manager. I can see how Pkl could ease the learning curve of nix and development of advanced configurations and modules.

@izelnakri commented on GitHub (Mar 28, 2024): > but things like configuration.nix or home manager config are usually functions. Not sure how one could use pkl for that and what’s the benefit over just using nix @adrian-gierakowski I think the benefit would be that `nix`, `home-configuration.nix` & `configuration.nix` could use Pkl documentation generator for documentation in the future and perhaps all the typed data structures would be easily debuggable, interactively peeked with `$ jpkl repl`. Both functions return an expected object and debugging/peeking that returned object before manipulation/development make things very productive including the benefit of being able to debug the imported flakes interactively. Missing or impartial documentation for data structures has been my biggest DX issue with learning and doing anything advanced with nix/home-manager. I can see how Pkl could ease the learning curve of `nix` and development of advanced configurations and modules.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#76