1{
2description = "A flake demonstrating input overrides.";
3inputs = {
4# Standard Nixpkgs input.
5nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
6
7# A hypothetical external flake we want to pin precisely.
8# We'll override its URL and revision to ensure a specific version.
9externalLib.url = "github:someuser/someflakerepo";
10externalLib.inputs.nixpkgs.follows = "nixpkgs"; # Ensure consistent nixpkgs usage
11};
12
13# This is where we define outputs, like packages or NixOS configurations.
14outputs = {
15self, # The flake itself
16nixpkgs, # The nixpkgs input
17externalLib, # The external flake input
18} @inputs: {
19
20# A simple package that uses the external library.
21packages.x86_64-linux.my-app = nixpkgs.mkDerivation {
22pname = "my-app";
23version = "0.1.0";
24
25# Use the external library's package.
26src = externalLib.packages.x86_64-linux.some-library;
27
28# Build inputs might also come from the external library.
29buildInputs = [
30externalLib.packages.x86_64-linux.some-library
31nixpkgs.hello # A standard Nixpkgs package
32];
33
34# Ensure build steps are clearly defined.
35# This is a placeholder; actual build steps depend on the library.
36installPhase = ''
37mkdir -p $out/bin
38cp ${externalLib.packages.x86_64-linux.some-library}/bin/some-library $out/bin/
39echo "#!/bin/sh\nexec $out/bin/some-library" > $out/bin/my-app
40chmod +x $out/bin/my-app
41'';
42
43# Add metadata for clarity.
44meta = {
45description = "An example app using an overridden external flake input.";
46license = nixpkgs.lib.licenses.mit;
47platforms = nixpkgs.lib.platforms.linux;
48};
49};
50
51# Example of how to override an input for testing or specific builds.
52# This is done within the `flake.nix` itself, or via `nix build --override-input`.
53# Here, we demonstrate a programmatic override for a specific output.
54# For a full override, you'd typically use `nix build --override-input externalLib ...`
55# or define it in a `flake.lock` file.
56
57# To actually override, you'd modify the `inputs` block or use CLI flags.
58# This example shows the *intent* of overriding.
59# A common pattern is to have multiple `flake.nix` files or use `nix build --experimental-features 'nix-command flakes' --override-input externalLib github:someuser/someflakerepo?ref=v1.2.3
60
61# For demonstration, let's assume we want to *force* a specific revision
62# for `externalLib` within this flake's outputs for a particular scenario.
63# This is usually handled by `flake.lock`, but can be simulated.
64# A more direct way to *use* an override is via CLI.
65
66# Let's simulate an override for a specific output scenario.
67# This is NOT how you'd typically override in `flake.nix` directly for all uses,
68# but shows how to construct a path using a potentially different input source.
69# The primary mechanism for overriding is `flake.lock` and CLI flags.
70
71# For this exercise, imagine we are defining an alternative build path.
72# The `flake.lock` file is the canonical source of truth for pinned inputs.
73# To *programmatically* define an override within `flake.nix` for a specific output:
74# This is advanced and less common than `flake.lock` or CLI overrides.
75
76# Let's focus on the `flake.lock` mechanism implicitly.
77# The `flake.lock` file will record the exact URL and revision.
78# If we were to run `nix flake lock`, it would generate a `flake.lock`.
79# We can *manually* edit `flake.lock` or use CLI overrides.
80
81# Example of how `flake.lock` might look for `externalLib`:
82# {
83# "nodes": {
84# "externalLib": {
85# "type": "github",
86# "owner": "someuser",
87# "repo": "someflakerepo",
88# "ref": "v1.2.3", # Or a specific commit hash
89# "sha256": "..."
90# }
91# }
92# }
93
94# To demonstrate the *effect* of an override, we can define a separate output
95# that *explicitly* uses a different input source.
96# This is more for illustration than typical `flake.nix` structure.
97packages.x86_64-linux.my-app-override = nixpkgs.mkDerivation {
98pname = "my-app-override";
99version = "0.1.0";
100
101# Here, we explicitly define a different source for the library.
102# This would typically be achieved via `nix build --override-input externalLib ...`
103# or by having a separate `flake.nix` for testing.
104src = inputs.externalLib.packages.x86_64-linux.some-library;
105# If we wanted to override the *input itself* for this specific output:
106# This is complex and usually handled by `flake.lock` or CLI.
107# The `flake.lock` is the primary mechanism for pinning.
108
109# For the purpose of typing practice, focus on understanding the `inputs` block
110# and how `flake.lock` records these. The CLI override is the practical way
111# to test different input versions.
112
113# Let's simplify: the core practice is defining the `inputs` block and understanding
114# that `flake.lock` pins them. The `override-input` CLI command is the tool.
115
116# The `follows` attribute ensures that if `nixpkgs` is already defined elsewhere
117# (e.g., by a parent flake), this flake will use that same `nixpkgs` instance.
118# This is crucial for consistency.
119
120# The `externalLib.inputs.nixpkgs.follows = "nixpkgs";` line ensures that
121# the `nixpkgs` used by `externalLib` is the same `nixpkgs` used by this flake.
122
123# The `nix build --override-input externalLib github:someuser/someflakerepo?ref=v1.2.3`
124# command is the practical way to test overrides.
125
126# For this exercise, the focus is on the `inputs` block structure and the concept.
127
128# Let's ensure the buildInputs are correctly referenced.
129buildInputs = [
130externalLib.packages.x86_64-linux.some-library
131nixpkgs.hello
132];
133
134installPhase = ''
135mkdir -p $out/bin
136cp ${externalLib.packages.x86_64-linux.some-library}/bin/some-library $out/bin/
137echo "#!/bin/sh\nexec $out/bin/some-library" > $out/bin/my-app-override
138chmod +x $out/bin/my-app-override
139'';
140
141meta = {
142description = "An app using an overridden external flake input (demonstration).";
143license = nixpkgs.lib.licenses.mit;
144platforms = nixpkgs.lib.platforms.linux;
145};
146};
147
148# A simple dev shell that includes the app and its dependencies.
149devShells.x86_64-linux.default = nixpkgs.mkShell {
150packages = [
151self.packages.x86_64-linux.my-app
152self.packages.x86_64-linux.my-app-override # Include the override version too
153nixpkgs.git
154nixpkgs.vim
155];
156# Shell hooks can be defined here if needed.
157};
158};
159}