Usage of zig init in a slight different way

Hi, apologise in advance, but I was looking at another thread (One Zig folder to store them all?) and add a couple of ideas that I decided not to put in that specific thread, but to create a new one.

This is mostly how zig init behaves, and again apologise if any of these “ways” already exist, since my time so far with zig has been short.

Currently to create a new project, running zig init:

mkdir foo
cd foo
zig init

I would change it to (I think is more intuitive):

zig init foo
cd foo

or (less intuitive)

zig init --name foo
cd foo

To use it on existing folder:

cd foo
zig init .

Also I would say that doing these steps would be helpful:

  • running git init automatically after zig init. This also could be avoided by adding a flag to not create a git repo (or any other VCS), something like --no-git or --no-vcs, but having it has a default is a good option.

  • also generating a README.md with a simple title and description like

# foo

This project is built with Zig, please run `zig build run` or zig build test`, for more information go to https://ziglang.org/ or https://ziglang.org/documentation/master/ or https://ziggit.dev
  • I would also add .gitignore files with content specific to ignore .zig-cache and zig-out, and probably ignore some other generated files that we usually care. Probably taking a look at gitignore.io - Create Useful .gitignore Files For Your Project, but I’m sure most people where know what to ignore.

  • a LICENSE file that could have a default “license”, MIT or whataver, all could be specific and change by passing flags

  • a .vscode/extensions.json with something like:

{
	"recommendations": [
                "ziglang.vscode-zig",
	]
}

this would would recommend, the “best of the best of the best” extension for Zig, useful for new zig users.

Probably there’s more stuff… just some ideas. Some of them assume people use vscode, probably because most do, and I’m not excluding others, but all of those could have some nice defaults with the ability to set something difference by using some base configuration, envs or flags.

That’s a lot of tooling stuff for things I don’t use and would wrap in a shell script to remove them right afterwards again. Use a different SCM, different mind-set and these (LICENSE, .vscode/*, README.md (README?), .gitignore, git init) are worthless. You think very github-OSS centric. There’s other forges, there’s non-OSS code, there’s other SCMs. What zig does right now only implies zig, and that’s what I like about it.

If you really re-create generic directory trees like these, I would suggest to automate it on your end in the way that satisfies your requirements, needs, and taste, and enjoy your soup just the way you like it :kissing:

10 Likes

My suggestion would be to contribute your ideas to this project, by adding new features to it or adding a new template to it:

I think this kind of functionality, that assumes a bunch of technologies that aren’t directly related to Zig is best kept in such a community project, that way everyone can experiment with different choices and people can customize it towards what they want.

7 Likes