add tooling to create a package tarball

[andrewrk]

Extracted from #14265.

This would have the following benefits:

• take into account the exclusion/inclusion rules (add inclusion/exclusion directives to build.zig.zon for deciding which files belong the package #14311)
• put build.zig.zon first in the tar (less important if make build.zig.zon contain all urls, including mirrors, and hashes of entire dependency tree #14309 is implemented)

Perhaps there could be some other linty checks that it would do by default, which would make people feel happy feelings when publishing a package.

However, there's kind of an odd downside here - this feature would not be necessary. By intention, any tarball generated by any service - even from any arbitrary commit - should work fine. The existence of this feature might mislead people into thinking that publishing a zig package is more complicated than it really is.

[thatoneguydownthere]

I was planning on creating a separate issue but found this issue and decided to post a comment here instead. I recently had a need to create a tar archive in a zig project and have implemented a feature in a locally cloned repo of ziglang where I integrated the creation of a ustar archive in std.tar. Would there be interest in me sending in a patch in the form of a pr?

[jcs090218]

I'm interested in this feature. It could benefit some unofficial centralized package managers.

[mattnite]

Hey just leaving a link to boxzer. It doesn't exactly implement this idea. It allows you to have multiple packages in a single repo that depend on one another using local paths. You then run the packager with a URL argument, and it creates multiple tarball packages out of the repo. The dependencies are changed from local to url dependencies based off the URL. Note, only works on macos due to a zig stdlib bug in recursive file walking.