Set zig version in environment or config

[bjacobowski]

It would be very helpful to indicate a zig version external to the command in some situations. I've run into several automated tools (e.g. neovim/lazy) that are expecting the normal zig command to work without a version or build.zig.zon (or when .minimum_zig_version isn't set). Could be an environment variable or config file somewhere.

[tamadamas]

I've failed with similar problem. My editor can't see zig installed.
So I've created with AI that shell script https://gist.github.com/tamadamas/b70c7d2eb59cc9a4c2b0052529f8c558

It seems working. It uses ZIG_DEFAULT_VERSION env and just calls anyzig with that version when anyzig fails to understand version

[tamadamas]

Actually I would prefer having somewhere in my ~/.config/anyzig/config.zig.zon with such content (and others options...)

.{
   .default_zig_version = "0.15.1"
}

[eamonburns]

Another use case I have is one-off, single-file experiments/bug repros.

I want to have a single .zig file that I can use zig run on, and I don't want to have to zig init for zls to be able to find the correct zig executable.

[tamadamas]

So my script gets even more important after closing #71 ^_^

[eamonburns]

@marler8997 - Reading your comment on #71, what do you think of having a default zig version that only works outside a project? So, if you have a build.zig.zon, you have to be explicit in what version(s) you support, but for elsewhere (be it in one-off zig files or when first running zig init for a project) it will use the default version.

[marler8997]

I think that would address my main concern so that might work? Maybe the config name could reflect that it's only to run zig commands outside a project? freelance-version? nobuild-version?

I'm curious what sort of use case or use cases were you thinking this would improve? I haven't really been in situations myself where this would be useful.

[eamonburns]

Maybe the config name could reflect that it's only to run zig commands outside a project?

ad_hoc_zig_version?

I'm curious what sort of use case or use cases were you thinking this would improve?

1. I often have single-file experiments I want to try out, but I don't want to go through the hassle of zig initing a project and messing with a build.zig.
2. When I am trying to make a minimal reproduction of a bug/problem, it is useful to be able to just create a single, self-contained file that I can zig run (which also makes it much easier to distribute). This is not too hard to do with zig VERSION run, but the ZLS integration in my editor is not so easy to manually override with a specific Zig version.

Side note: ZLS gives the following error when editing a .zig file outside of a project:

[Warning] zig executable could not be found

[tamadamas]

I think that would address my main concern so that might work? Maybe the config name could reflect that it's only to run zig commands outside a project? freelance-version? nobuild-version?

I'm curious what sort of use case or use cases were you thinking this would improve? I haven't really been in situations myself where this would be useful.

Editor support?
I've checked that VSCode and Zed know nothing of anyzig. They just call "zig" from PATH and fail to found. Do we expect having "default original zig" and "anyzig" together? I this situation, Could we follow Golang approach?
I think, in go, they have one global and every project can specify version that "go" tools will use.

@marler8997

[nhawke]

Some other (minor) reasons to support this that tripped me up recently:

1. Currently, the anyzig-bin AUR package installs the anyzig binary with the name anyzig rather than zig. The package maintainer made the valid point that anyzig is not currently a true drop-in replacement for zig because you can't use it outside a zig project without specifying a version explicitly.

2. Similar to the above comment, I was unable to test a bug-fix using anyzig and an ad-hoc zig file. I had to go fetch a full zig project to call zig fmt without a version.

3. (maybe intended behavior / unavoidable?): I couldn't call zig fmt with anyzig when the cwd was outside the zig project (e.g. when i edited a file using vim zig-project/foo.zig rather than cd zig-project && vim foo.zig).

---

I agree that this "default" version should only be used if there's no explicitly specified version in either a build.zig.zon or the CLI.

[marler8997]

Thanks for the info @nhawke, I think yes, we should add support for a default zig version, so long as it's "outside" a project. I think currently "outside a project" means there is no build.zig file in the current or any parent directory.

I think a new setting (similar to how the verbosity setting works) should do. I'd make it "opt-in" which would mean updating the error message to something like this:

no build.zig to pull a zig version from, you can:
  1. run 'zig VERSION' to specify a version
  2. run from a directory where a build.zig can be found
  3. configure a default version to use outside projects with `zig ad_hoc_version VERSION`

Still not sure on the best name, ad_hoc_version might be the best idea so far?

[eamonburns]

Likely just a typo: change zig ad_hoc_version VERSION to zig any ad-hoc-version VERSION (typo was omitting "any". Additionally change it to kebab-case for consistency with list-installed and set-verbosity)

(Might want to name it set-ad-hoc-version)

[nhawke]

Still not sure on the best name, ad_hoc_version might be the best idea so far?

I don't mind default_version (with corresponding command zig any default-version). I think "ad hoc version" is harder to intuit, wheras "default version" communicates "this version will be used if another version is not specified"

[eamonburns]

"default version" communicates "this version will be used if another version is not specified"

I agree that that is what it communicates, but that isn't exactly how it acts.

If there is a build.zig but no minimum_zig_version in build.zig.zon, then "another version is not specified", but anyzig would fail to use the "default version" (on purpose).