import function: relative to package root, or relative to current file, or both?

[andrewrk]

Currently, @import("foo.zig") looks for foo.zig relative to the package root.

Another way to do it would be to have it look relative to the directory of the file doing the import.

Another way would be to have a rule like "if it starts with ./ or ../ then look relative to the directory of the file doing the import".

Yet another way be to have 2 different import builtin functions for each of these behaviors.

Which way is best? I'm not sure. Status quo seems to work fine for the use cases I've thought of. It's closer to how it works in C with #include statements. But being closer to C isn't necessarily better or worse in this case.

Having it work only one way instead of two ways would be preferable, since that aligns with the design goal of orthogonality (limit programmer choices in order for code to generally look and feel the same).

Anyone have example use cases to inform how we can choose which way is best?

[raulgrell]

I brought this up on IRC a couple of days ago. In C, I'm either including an <external_dependency.h> or an "internal_dependency.h".

• Any libraries I am using have to be defined in the build process and must be included from an includePath. The standard library is an external dependecy.

• If the project is broken up into modules, includes within the module are either relative (internal). Includes in other must be defined for that module at compile-time (external) .

• If I'm just importing other files within that project, or a library I have the source for (like a single header file), that bit of code be part of the "source tree" and is an internal dependency.

However, this is just the way I "namespace" my projects in C. It forces me to pay attention to dependencies and go through sanity checks when turning parts of my code into standalone "modules". Status quo is fine, and might keep things sane once the build system is fully fleshed out.

Potential cons include increased effort when moving around source files with very complicated dependency trees, and there's a little voice inside me saying your "reproducible builds" objective might be easier if you disallow relative imports.

---

As for how to do it if you so choose, I very much like the Node way of doing it: relative if import string begins with ./ or ../.

This way we keep the single import function

[andrewrk]

Argument in favor of paths relative to current file: if you drop files from one project into another, they will work unmodified.

We'll expose both package root and source file name in a compile variable, so technically regardless of the default, you can get the other behavior: Example: @import(@compileVar("pkg_root_dir") ++ "/foo.zig")

[glyh]

Is @compileVar renamed something else? I can't use it on 0.11.0-dev.2934+1b432072b

[nektro]

@compileVar was likely what build_options became, given the comment was from 2017

but that example wont work regardless because @import paths have to be a string literal ever since #2206

[glyh]

@nektro Then how should I retrieve the root dir of the current package? I found this @import("@root") but I don't find any information as to what is the type of this thing..

related: #2189

[nektro]

@import is always relative to the file. so you have to path/to/file or ../ your way to the right spot. see also #6279

@import("root") and a few others are described here: https://ziglang.org/documentation/master/#import

further stuff should be taken to https://github.com/ziglang/zig/wiki/Community