webflo-dev · August 14, 2024 12:06 · May 9, 2019 · May 9, 2019 · May 9, 2019
diff --git a/nix_inputs.md b/nix_inputs.md
@@ -34,4 +34,10 @@ They must also be propagated to downstream runtime environments, because any Pyt
 This is why Python packages that export Python modules need to be in `propagatedBuildInputs`.
 
 However consider C libraries that get compiled into shared objects. These shared objects are linked into by your C executable. Downstream users of your executable don't need to know about your the shared objects that your executable uses.
-This is why C packages that expose C libraries are put into `buildInputs` and not `propagatedBuildInputs`.
+This is why C packages that expose C libraries are put into `buildInputs` and not `propagatedBuildInputs`.
+
+Note that when we use `nix-shell`, we are essentially entering into the build environment.
+This could mean that packages that are in `propagatedBuildInputs` or `buildInputs` which expose CLI executables may not
+appear in the build environment. It is important to realise this is a __may__ as it depends on the derivation interpretation.
+
+It's important to be explicit. So if you want something to always appear in the build environment and runtime environment, then it should be added to both.
diff --git a/gistfile1.txt → nix_inputs.md b/gistfile1.txt → nix_inputs.md
diff --git a/gistfile1.txt b/gistfile1.txt
@@ -0,0 +1,37 @@
+# Understanding Nix Inputs
+
+Every Nix derivation produces a Nix store output that has 3 things:
+
+* Executables
+* Libraries
+* Data
+
+Executables are always exported using the `PATH` environment variable. This is pretty much automatic.
+
+Libraries are exported in environment variables that are dependent on the language environment you are in.
+For example `PYTHONPATH` for Python. Or `C_INCLUDE_PATH` for `gcc`. This is usually done via a setup hook.
+
+Data is often not exported with any special environment variables, unless you explicitly refer to them. You
+can do this within a Nix expression by simply interpolating the derivation as a string which will evaluate
+to their Nix store path.
+
+During the transformation from a Nix derivation to a Nix output.
+We differentiate build environments from runtime environments.
+Here we are not considering cross-compilation.
+We are assuming that build and run environments are on the same machine.
+
+* `buildInputs` - Dependencies that should exist in the runtime environment.
+* `propagatedBuildInputs` - Dependencies that should exist in the runtime environment and also propagated to downstream runtime environments.
+* `nativeBuildInputs` - Dependencies that should only exist in the build environment.
+* `propagatedNativeBuildInputs` - Dependencies that should only exist in the build environment and also propagated to downstream build environments.
+
+The above is not strictly true all the time because it depends on the derivation functions you are using.
+
+The specific derivation function may have a different interpretation of what "propagation" means. And what environment variables they will propagate.
+
+But basically we can see that most Python modules for a Python package must exist at runtime.
+They must also be propagated to downstream runtime environments, because any Python package that loads your package must be able to load your package's dependencies.
+This is why Python packages that export Python modules need to be in `propagatedBuildInputs`.
+
+However consider C libraries that get compiled into shared objects. These shared objects are linked into by your C executable. Downstream users of your executable don't need to know about your the shared objects that your executable uses.
+This is why C packages that expose C libraries are put into `buildInputs` and not `propagatedBuildInputs`.
No results found