# Understanding std paths in Zig: how to tell package vs module vs types vs values vs aliases vs other items? **URL:** \ **Category:** Explain\ **Tags:** zig-docs\ **Created:** [April 21, 2026, 12:28pm UTC](https://ziggit.dev/t/understanding-std-paths-in-zig-how-to-tell-package-vs-module-vs-types-vs-values-vs-aliases-vs-other-items/15096 "2026-04-21T12:28:58Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![vulpesx](https://ziggit.dev/user_avatar/ziggit.dev/vulpesx/32/3989_2.png) [@vulpesx](https://ziggit.dev/u/vulpesx)\ **Post date:** [April 21, 2026, 1:18pm UTC](https://ziggit.dev/t/understanding-std-paths-in-zig-how-to-tell-package-vs-module-vs-types-vs-values-vs-aliases-vs-other-items/15096/3 "2026-04-21T13:18:30Z")
### A package is what you put as you dependencies, usually your project would be a single package, but larger ones could be multiple packages. A package could be any git repository or archive and is not restricted to only zig dependencies. ### A _zig_ package is a package with a `build.zig.zon`. That communicates more information to the package manager such as name, version, what files/dirs are part of the package (and what is not by omission) etc. note that a `build.zig` is optional, but is how packages would export modules, artifacts etc. Without it dependents only get raw files/dirs. ### A module is purely a build system concept. It is a tree of source files (zig, c or cpp), linked objects, includes, and imports of other modules (imported modules must have a root zig file since imports are a zig concept). Modules can be exported which is the preferred way to reuse zig code. `std` and `builtin` are modules implicitly added to your imports. Other modules have to be added explicitly. > files can only appear in one module in an import tree. ### A compile artifact is the actual executable, library or object; it gets its source via a root module and its imports. (all zig source for an artifact is compiled in one unit, unlike c/cpp source) ### A type is a description of data. There are some that are intrinsic parts of the language like: `bool`, `f32`, the variably sized ints, etc. And user defined types: `struct`, `enum`, `union`, `opaque`. ### A value a value is actual data, it must have a type to describe its data. What is a mind bender is types themselves are also values (of type `type`), but this is quite powerful. ### A namespace In zig, user defined types (`struct`, `enum`, `union`, `opaque`) do double duty as namespaces. This includes files, which are just `struct`s (yes, you can give them fields, and instantiate files). Types which only function as namespaces will be `snake_case`, but (user defined) types that are intended to be instantiated use `PascalCase` (assuming the author follows the style guide, it is not enforced) Since we are on the topic, functions use `camelCase`, and variables/constants use `snake_case`. [official style guide](https://ziglang.org/documentation/0.16.0/#Style-Guide) ### An alias Is just binding a name to a type, the first binding according to source definition of the type will be the canonical name of the type (excluding intrinsic types) ### Accessing things zig uses `a.b` as a universal access syntax, it could be a declaration on a type (`const`, `var`, `fn`). A field of a user defined type, or calling a function on an instance of the type the `fn` is defined in. where `a` is a type, it can be ommited so long as type is provided to the expression in another way, e.g `const a: Foo = .empty`, or `foo(.bar)`. note that `.a catch { ... }` does not work, same with `orelse`, due to limitations in the compiler. * * * `std.Io.Operation.FileWriteStreaming.Result` `std` - module and namespace `Io` - Instantiable type and namespace `Operation` - Instantiable type and namespace `FileWriteStreaming` - Instantiable type and namespace `Result` - Instantiable type --- _[View the full topic](https://ziggit.dev/t/understanding-std-paths-in-zig-how-to-tell-package-vs-module-vs-types-vs-values-vs-aliases-vs-other-items/15096)._