Use of the name Zig in package names

Brainstorming
1

I believe it stems from this discussion (which I recommend reading to the end)

which resulted in this commit

Personally, I strongly disagree with the conclusion that zig in the package name is always redudant.

If your project is an original project, then yes, I agree that having zig in the name is redundant.

But the Zig build system does not only support packaging Zig code but also C, C++ and code written in any other language (and even files that aren’t code at all). If your package is a set of bindings for a library, let’s say libfoo, and what sets your package apart from the upstream project is that it provides bindings for the Zig language (as opposed to just packaging the upstream project as-is for the Zig build system), then a package name like libfoo-zig is useful and makes sense, just like a name like libfoo-rs or libfoo-cs for Rust or C# bindings would.

3 Likes
2

I believe the equilibrium we’re going for here is analogous to how it works in Rust. The Rust Foundation, and the rustaceans generally, don’t like it when “rust” shows up in a Cargo package name, unless the package concerns Rust as a language. If it’s useful to tag a package as being a Rust version of whatever, that’s what -rs is for.

An example of “concerns Rust as a language” is rust-analyzer, which is not a general-purpose analysis tool which happens to be written in Rust, it’s a crate which specifically analyzes Rust code. A code analysis tool which happens to be written in Rust can be code-analyzer-rs, that’s always fine.

Analogously, we’re all better off if -zig or zig- means code which concerns Zig as a language, with topic-z as a tag showing “the Zig version of topic”. It could be -zg I suppose, I personally like just -z though, with or without the hyphen. I don’t think either poses any risk of confusion, in that there aren’t a lot of other reasons elsewhere to stick a zed on the end of names. And it leaves the full language name available to signal something useful.

Edit: specifically for bindings, something like libfoo-zbind might be best. It disambiguates three possible cases down to one: libfoo-zbind is Zig bindings for a C library, it is not a translation of libfoo into Zig, and it is not a C library writen in Zig.

All of those are possible with either libfoo-zig or just libfoo-z. This came up awhile back with an ambiguous name for a library which wrapped jemalloc as a Zig allocator, and there’s another package out there which is a translation of jemalloc into Zig.

3

Does Rust support packaging projects written in languages other than Rust, to support integration into projects written in languages other than Rust?

If you’re writing a Zig program and you want to use some well-known library (usually written in C/C++), say raylib, and someone has already packaged it for the Zig build system, you might end up with a dependency graph like this:

  • Your program
    • raylib bindings for the Zig language
      • raylib ported to/packaged for the Zig build system (with no source modifications)

What package names would you expect the “bindings” and “build system port” packages to have, respectively?

If you ask me, for the plain build system port, the package name raylib is obvious, because it is raylib.

For the bindings,

  • Just calling it raylib doesn’t tell the user how it’s different from the original raylib.
  • raylib-bindings doesn’t provide an answer for which language the bindings are; they could be C bindings for a library written in C++ for all I know.
  • raylib-zig-bindings gets the idea across unambiguously, but it’s a bit of a mouthful.
  • raylib-zig is good compromise, and I fail to see how it could mean anything but “raylib, but for Zig programs”.

If we subscribe to the idea that

It is redundant to include “zig” in this name because it is already within the
Zig package namespace.

(which I don’t in the context of bindings), and an affix like zig is undesired as an indicator that “the thing that sets this apart from some original project is that it’s ‘ziggified’/for programs written in Zig”, then some different cutesy affix like z is just as pointless and undesired. You’re just cleverly sidestepping the original issue.

2 Likes
4

You’re nicely illustrating why -zig is a poor choice here.

-zbind and -zbuild strike me as perfect for those use cases.

raylib-zig doesn’t distinguish those cases at all, and relies on knowing that raylib is not a zig program. My first guess would be that it’s a port of raylib to Zig, but that should also be called something else.

5

Should every package in allyourcodebase be renamed to include the -zbuild suffix, in your view?

6

I feel it’s a bit overly restrictive to not be allowed to use zig in a project that is not directly created by the zig language, but I also don’t have any expectations that a tool is official just because of its name. I would say that if you want to mark a project as official it should have ziglang in the name, as that is the name of the org on github[1], but I don’t think I’d assume a name is official because that’s in the name either. What matters mostly is that the software is good right?

  1. In fact, I think the only way that would make me think it’s an official project is by seeing that it’s in a repository under www.github.com/ziglang. ↩︎

1 Like
7

I think you’re coming at this backward.

There are a few reasons not to put zig in the name of your package. One of them is that Andrew Kelly doesn’t want us to do that. I consider that good and sufficient reason not to. I could go over other reasons, again, but that would get redundant.

Pointing that out doesn’t impose on me, or anyone else, an obligation to name everyone’s software for them. Just don’t use -zig that way. Anything else is just a helpful suggestion.

All but two of those packages just use the package name, and put the information about the Zig build system in the tagline. The other two should remove the -zig suffix, because it isn’t necessary, and because the guy responsible for the word Zig referring to a programming language, which he created, doesn’t want that word used that way. Period. It’s very easy to respect that wish, it costs you nothing, and it seems rude to go against it.

Do I think they should all have a -zbuild suffix? Sure why not. Also not really. I don’t have a strong opinion on the subject. It was proposed in the context of keeping two things separate, which doesn’t really apply here.

This is not about permission, it’s about respect. What you can do and what you should do are separate matters.

3 Likes
8

For projects that are not libraries I am not using the zig- prefix.

I am using the zig- prefix for my zig packages. The reasons are:

  • Zig expects the package name to be the enclosing folder name.
  • Github repositories names define the folder name (therefore they also define the package name).
  • For all the zig libraries that I am packaging I am using the zig- prefix. For example zig-decimal, go-decimal, rust-decimal repositories for a decimal library written in each language.
3 Likes
10

There is a post by @andrewrk:

I think you are getting the project name mixed up with the Zig package name. I am not suggesting to rename your source code repository. I think zig-wlroots is the best name for the source repository.

The prefix “zig-” in the name field of build.zig.zon is, however, entirely redundant and should be omitted. This is so blindingly obvious to me that I’m finding it difficult to even express any reasoning for it.

7 Likes
11

Blind appeal to authority is boring. Andrew is not an infallible human being and he should be able to be challenged just like anyone else. In the linked issue, there are several core members who disagree with his conclusions, and the last few comments about the Zig build system/package manager being a multipurpose, multi-language tool (unlike Cargo or NPM) were never addressed.

Ultimately, the question of what is an appropriate package name is not very important. One of the great things about Zig is that the community and package ecosystem is decentralized and that everyone is free to write their code or name their things however they want so long as it compiles and builds. My only reason for bringing this up in the first place was to 1) provide an answer to the question of where the “no zig-” suggestion came from and 2) clarify that it’s just a suggestion, not the law, while offering an alternative viewpoint that shows that there might be more nuance to it than previously discussed.

5 Likes
12

There are few languages where the names of their packages and/or libraries include the name of the language. How many projects in C, C++, Fortran. Pascal, LISP have the language in their name?

That something is Ziggy is nearly always obvious from context.

13

This doesn’t seem to have gone too far, but I just don’t understand discouraging people from contributing in any community by making it seem like you’ll get yelled at for doing something you’re excited about, for free.

I understand the debate, but even as a graybeard, I admit that whenever I read that a community shames or sues people over “their brand,” I’m just not going to be very motivated to be a part of it. I don’t think that’s happening here, but it happens and the natural question is: so do they want me or no? The perception matters.

14

I don’t know how brand names entered into this discussion. That’s not really the point, is it? It’s really a question about namespaces.

Clearly, a project on GitHub is in the GitHub project namespace, and thus disambiguating not only between languages makes sense but also between users. That’s why references to GitHub projects often include a user name, language, and project name. For example, https://github.com/andrewrk/node-astar.

However, within package.json, that is an NPM package, so it’s already understood to be in the Node.js namespace, and therefore putting “node” in the name would be redundant.

Similarly, within cargo.toml the crate name is understood to be a Rust crate, and so putting “rust” or “rs” is redundant.

Similarly, within pyproject.toml the name is understood to be a Python package name, and so putting “python” or “py” is redundant.

Similarly, within a build.zig.zon file, that package name is the Zig package name, and therefore is implicitly in the Zig package namespace.

By using the word “zig” inside this name, what are you communicating? It’s already a Zig package. The word “zig” is redundant apart for exceptions having to do with the language or toolchain itself.

As for Zig build system being a multipurpose, multi-language tool, I think that’s a fair argument. My position is that, while many use cases are supported, the toolchain clearly favors Zig as a primary use case, making “zig” the implicit default for packages, and other things require disambiguation.

This is also the case with other package managers, which allow arbitrary things to be uploaded. Case in point, Zig package on PyPI! NPM and Cargo also allow uploading arbitrary files.

Even fully accepting the multipurpose argument, “zig” is a terrible disambiguator. Is it bindings? Is it a module? Is it more than one module? Is it a library with a C ABI but the source is in Zig? Is it a different project packaged with the zig build system? Perhaps the project maintainer just used “zig” because they are using the Zig package manager. A casual glance at the package does not tell you the answer. I suggest to use more precise language. The bottom line is that the word “zig” communicates next to nothing in this context.

Ultimately, it is just a convention, and while I have a strong opinion on what a good convention is, it’s not going to hurt anybody if the picture is hung a little crooked on the wall.

As for ZSF trademarks and branding, it’s only a problem if people are being deceived. In other words you’re only going to create beef if you claim to speak for ZSF or if you say you are a Zig core team member when you’re not. Pretty difficult to do accidentally.

1000%

19 Likes