I am referring to config or .env files used across projects. I looked into the solutions for my current project and in the end just used a config.zig file with public consts.
Though I realised this doesn’t make a lot of sense since it needs to be compiled. And I would like to have the option of hotswapping variables on the server when needed. I guess it has to be dynamic allocation?
It doesn’t have to be dynamic, if you have a known upper limit on size or are able to make a reasonable assumption on size you can use stack memory.
I looked into the solutions for my current project and in the end just used a
config.zigfile with public consts.
This is one of the uses for the .zon format. It parses more-or-less 1:1 into a Zig struct, so you can define a config struct in your application and load it from/to disk easily.
Did not think of that, it sounds great, thanks!
I’ve been using .zon files for both config and env. They are different since env.zon often has secrets that you don’t want to commit, just like .env, the only difference being that you embed env.zon into binary at compile-time with @import, while .env secrets are meant to be passed as process’ env vars at runtime. Not too sure, but I believe there’s no difference in terms of security between the two.
I think there is a security difference between the two. env.zon being in the binary would allow for strings to find those embedded in the binary, whereas the runtime loading will not have that issue.
What if binary is never installed?
Btw, it’s also possible to load env.zon at runtime with std.zon.parse.fromSlice.
Not sure what you mean. My point is that if you @import a file, it becomes part of the binary and those values will be retrievable from the resulting artifact. When you distribute that artifact, anyone with the artifact will have your env.zon file as part of the binary.
I agree. What I meant was the same distinction the Zig Build System makes by distinguishing between b.addInstallArtifact and b.addRunArtifact.
The resulting binary needs to live somewhere, if you want to run it.
On most operating systems this means the filesystem, only some operating systems (like Linux) support running a binary which lives entirely in RAM.
The Zig build system puts compiled binaries, which aren’t “installed” (which is really just copying files to specific locations) into the cache directory (by default .cache in the project directory/next to the build.zig file).