https://bugzilla.redhat.com/show_bug.cgi?id=2334903 --- Comment #11 from Jan Drögehoff <sentrycraft123@xxxxxxxxx> --- Hey, zig maintainer here > I also tried to find documentation for "zon", but I couldn't find anything relevant. > Is this a builtin tool of the zig toolchain or some third-party package manager for zig? > I found no references to it in https://github.com/ziglang at all. there used to be a basic explanation but it appears it was removed from website at some point. zon stands for Zig Object Notation and is used by Zig for `build.zig.zon`, a project file where metadata is stored. This includes: - project name - version - relevant paths/files (used for hash generation) - dependencies where dependencies is an object within itself that can contain either a url and a hash or a local relative path. the url can point to any arbitrary file, archive or git repository with names used for dependencies being modifable so a given dependency may be given a different name depending on the project. > I think the latter form should be preferred. The one without "namespacing" doesn't really make sense, it usually refers to package names that already exist in Fedora. Other language ecosystems also use syntax like "bundled(crate(foo)) = 1.2.3" or "bundled(golang(github.com/foo/bar)) = 2.3.4" since this matches the virtual Provides that those crates / Go libraries *would* have if they were packaged instead of bundled. the namespace bundled used for other languages tend to be automatically generated from metadata provided by a given project. Usually this includes some kind of named identifier, which zig lacks. As mentioned zig dependencies can point to any arbitrary content with the only globally identifying factor being the hash. This makes it pretty difficult to specify all the bundled provides since they can be zig projects or C projects or even something else. The for the future is to have 2 form of bundled provides generation: - the zon namespace that includes the hash for every remote dependency - the zig namespace where it iterates through every zig dependency used and uses the name specified in build.zig this will only account for zig dependencies directly and includes the identifier used within the upstream build system so non-zig dependencies would need to be provided manually. Until then the stop-gap solution is to simply use plain provides, the river package already does this as well. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2334903 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202334903%23c11 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
