Skip to content

Commit 2bd75af

Browse files
authored
Merge pull request #91 from numtide/docs_mar12
Updated documentation
2 parents 7ae2142 + a4684ea commit 2bd75af

File tree

13 files changed

+876
-545
lines changed

13 files changed

+876
-545
lines changed

README.md

Lines changed: 105 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -15,9 +15,9 @@
1515

1616
</div>
1717

18-
blueprint is an opinionated library that maps a standard folder structure to
19-
flake outputs. It makes common use cases easy both for the author and
20-
consumers.
18+
blueprint is an opinionated library that maps a standard folder structure to flake outputs, allowing you to divide up your flake into individual files across these folders. This allows you to modularize and isolate these files so that they can be maintained individually and even shared across multiple projects.
19+
20+
Blueprint also makes common use cases easy for both the author and consumers.
2121

2222
Eg:
2323

@@ -44,28 +44,15 @@ Support for:
4444

4545
and more!
4646

47-
## Documentation
48-
49-
* [Getting started](docs/getting-started.md)
50-
* [Configuring blueprint](docs/configuration.md)
51-
* [Folder structure mapping](docs/folder-structure.md)
52-
5347
## Rationale
5448

55-
Nix is just a tool. It should help you, and stay out of the way. But because
56-
it's so flexible, everybody goes through a long period where they figure out
57-
how to structure their repo. `flake.nix` files become noisy with boilerplate.
49+
Nix is just a tool. It should help you, and stay out of the way. But because it's so flexible, everybody goes through a long period where they figure out how to structure their repo. `flake.nix` files become noisy with boilerplate.
5850

59-
By making a few opinionated choices, we're able to cut 99% of the glue code
60-
you would find in most repos. A bit like Ruby on Rails or NextJS did for web
61-
frameworks, we do it for Nix packages. We map folder and files to flake
62-
outputs.
51+
By making a few opinionated choices, we're able to cut 99% of the glue code you would find in most repos. A bit like Ruby on Rails or NextJS did for web frameworks, we do it for Nix packages. We map folder and files to flake outputs.
6352

64-
In some ways, this is the spiritual successor to `flake-utils`, my first
65-
attempt at making flakes easier to use.
53+
In some ways, this is the spiritual successor to `flake-utils`, my first attempt at making flakes easier to use.
6654

67-
Blueprint isn't suitable for complex flakes but it does allow you to easily
68-
break out once your project becomes complicated beyond its capability.
55+
Blueprint isn't suitable for complex flakes but it does allow you to easily break out once your project becomes complicated beyond its capability.
6956

7057
## Design principles
7158

@@ -80,3 +67,101 @@ break out once your project becomes complicated beyond its capability.
8067
* [std](https://github.com/divnix/std)
8168
* [snowflake-lib](https://github.com/snowfallorg/lib)
8269
* [clan-core](https://git.clan.lol/clan/clan-core) is an all-in-one solution to manage your deployments.
70+
71+
## Full Documentation
72+
73+
You can find the [full documentation here](https://numtide.github.io/blueprint/main/).
74+
75+
## Quickstart
76+
77+
Meanwhile, if you're ready to get started right away, here's what you do.
78+
79+
1. [Install Nix](https://nix.dev/install-nix) or use NixOS.
80+
2. Run `mkdir my-project && cd my-project`
81+
3. Run `nix flake init -t github:numtide/blueprint`
82+
83+
Now you're ready to create some folders and special files. The full documentation shows you all the folders and special files available, but for now let's create a couple of development shells, and a formatter.
84+
85+
Remember, the goal is to divide up the flake.nix file into individual modular parts. This not only helps keep your flake.nix file size down, it lets you create reusable modules that you can easily drop into other projects.
86+
87+
Let's create a package the builds a docker container from our source, assuming your source lives in a folder called src off the root folder. Assume your src entry point is a file called hello.py; in this example, just put the following in `hello.py`:
88+
89+
```
90+
print('Hello from docker!')
91+
```
92+
93+
Also from the root folder create a folder called `packages`, and under that a folder called `docker-python-hello`. Inside that folder create a file called `default.nix`, and place the following in it:
94+
95+
```nix
96+
{ pkgs, system, ... }:
97+
98+
let
99+
python = pkgs.python3;
100+
101+
pythonApp = pkgs.stdenv.mkDerivation {
102+
pname = "my-python-app";
103+
version = "1.0";
104+
src = ../../src;
105+
106+
installPhase = ''
107+
mkdir -p $out/app
108+
cp hello.py $out/app/
109+
'';
110+
};
111+
112+
rootImage = pkgs.buildEnv {
113+
name = "my-docker-root";
114+
paths = [ python pythonApp ];
115+
pathsToLink = [ "/bin" "/app" ]; # python will be linked in /bin
116+
};
117+
in
118+
pkgs.dockerTools.buildImage {
119+
name = "my-python-hello";
120+
tag = "latest";
121+
122+
fromImage = pkgs.dockerTools.pullImage {
123+
imageName = "python";
124+
finalImageTag = "3.11-slim";
125+
imageDigest = "sha256:7029b00486ac40bed03e36775b864d3f3d39dcbdf19cd45e6a52d541e6c178f0";
126+
sha256 = "sha256-lUrhG5Omgdk81NmQwQTo4wnEfq2+r2nGePpgTSYgVU0=";
127+
};
128+
129+
copyToRoot = rootImage;
130+
131+
config = {
132+
WorkingDir = "/app";
133+
Cmd = [ "python" "/app/hello.py" ]; # will now work since python is in /bin
134+
};
135+
}
136+
```
137+
138+
This will build an image into a folder called results; to do so, type the following:
139+
140+
```
141+
nix build .#docker-python-hello
142+
```
143+
144+
Note that the name to use must match the name of the folder under the packages folder.
145+
146+
Also notice that nix is able to find the default.nix file thanks to Blueprint. You can then load the image and run it by typing:
147+
148+
```
149+
docker load < result
150+
docker run --rm my-python-hello:latest
151+
```
152+
153+
This should print the message:
154+
155+
```
156+
Hello from docker!
157+
```
158+
159+
Note that result is really a symbolic link to a tar.gz file containing the image in the store.
160+
161+
You can view your image by typing the usual:
162+
163+
```
164+
docker images
165+
```
166+
167+

docs/configuration.md

Lines changed: 0 additions & 77 deletions
This file was deleted.
Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
nav:
2+
- install.md
3+
- folder_structure.md
4+
- built_in_templates.md
5+
- configuration.md
Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
# Using Templates
2+
3+
Blueprint comes with several templates to help you get started with your project.
4+
5+
> Note: Feel free to contribute new templates!
6+
7+
To install from a template, use the following format; for example, to use the template called system manager, type:
8+
9+
```
10+
nix flake init -t github:numtide/blueprint#system-manager
11+
```
12+
13+
where we appended a hash symbol followed by the template name.
14+
15+
## Default Template
16+
17+
Init command:
18+
19+
```bash
20+
nix flake init -t github:numtide/blueprint
21+
```
22+
23+
This is a bare-bones project as described in [install](./install.md).
24+
25+
## NixOS and Darwin Shared Homes Template
26+
27+
```
28+
nix flake init -t github:numtide/blueprint#nixos-and-darwin-shared-homes
29+
```
30+
31+
This template is a bit of an example plus a template. You'll want to study all the files carefully. It shows how you can define and reuse modules, in this case nixos and home-manager.
32+
33+
Look carefully at the folder structure; in this case we're using `hosts` and `modules` folders which are both picked up by Blueprint.
34+
35+
If you drill down into the folders, you'll see inside the `hosts` folder, are a `my-darwin` folder and a `my-nixos` folder, both of which are imported by Blueprint. This defines the two hosts called `my-darwin` and `my-nixos`.
36+
37+
Their respective configuration files both import a shared `modules/nixos/host-shared.nix` module between them.
38+
39+
Also, both hosts define a `me` user and their home-manager configuration simply imports `modules/homes/home-shared.nix`.
40+
41+
Finally, notice in the root `flake.nix` we're adding the home-manager and nix-darwin inputs, which serve as dependencies for managing home configurations and macOS integrations, respectively.
42+
43+
The idea with this template is that you can use this example to get started on how to share configurations between different system and home environments on different hosts.
44+
45+
46+
## Toml-DevEnvs
47+
48+
Members of your team might be intimidated by Nix and flake files, and prefer a more traditional method of configuring their devshells. As such, we provide full support for TOML files.
49+
50+
For more information, please visit our [devshell repo](https://github.com/numtide/devshell), which is what powers this template behind-the-scenes.
51+
52+
## System Manager Template
53+
54+
```
55+
nix flake init -t github:numtide/blueprint#system-manager
56+
```
57+
58+
Notice that the root flake.nix file we're adding the system-manager input, which is our own project. You can find it on GitHub at [system-manager](https://github.com/numtide/system-manager), where you can read more information on how to use it.
59+

docs/content/reference/configuration.md renamed to docs/content/getting-started/configuration.md

Lines changed: 24 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -1,24 +1,38 @@
11
# Configuration
22

3-
The flake.nix file offers a few configuration options:
3+
In this section we describe the blueprint configuration options:
44

55
* **prefix**: This lets you specify a directory to hold the folders other than the flake.nix location.
66
* **systems**: Defines which systems the project should be used and deployed on.
7-
* **nixpkgs.config**: If set, Blueprint will create a new instance of nixpkgs for each systems.
8-
* **nixpkgs.overlays**: If set, blueprint will create a new instance of nixpkgs for each systems.
7+
* **nixpkgs.config**: If set, Blueprint will create a new instance of nixpkgs for each system.
8+
* **nixpkgs.overlays**: If set, blueprint will create a new instance of nixpkgs for each system.
99

10-
Below we provide more detail on each, along with examples.
10+
These are available by changing the `flake.nix` output invocation with additional parameters.
1111

12-
[TODO: More detail and each; meanwhile I've copied in the current configuration.md file]
12+
Below we provide more detail on each, along with examples.
1313

1414
## prefix
1515

16-
Set this if you want to load the blueprint from a directory within the repositiry other than the flake location.
16+
Set this if you want to load the blueprint from a directory within the repository other than the flake location.
1717

1818
Default: "."
1919

2020
Type: string.
2121

22+
For example, add the following prefix line to your output invocation:
23+
24+
```nix
25+
outputs = inputs:
26+
inputs.blueprint {
27+
inherit inputs;
28+
prefix = "nix/";
29+
};
30+
```
31+
32+
Then, you can add a `nix` folder inside the same folder that holds your flake file, and place all your folders within this `nix` folder.
33+
34+
> **Tip:** Although you can choose any folder you like, we recommend the name "nix" for your folder, as this is becoming the defacto standard.
35+
2236
## systems
2337

2438
Defines for which systems the project should be used and deployed on.
@@ -40,13 +54,13 @@ Example:
4054

4155
## nixpkgs.config
4256

43-
If set, blueprint will create a new instance of nixpkgs for each systems, with the passed config.
57+
If set, blueprint will create a new instance of nixpkgs for each system, with the passed config.
4458

4559
Default: `inputs.nixpkgs.legacyPackages.<system>`.
4660

4761
Type: attrset.
4862

49-
Example:
63+
For example, the following sets the allowUnfree attribute of nixpkgs.config to true:
5064

5165
```nix
5266
{
@@ -61,13 +75,11 @@ Example:
6175

6276
> NOTE: It's better to use `perSystem` composition style instead of overlays if you can.
6377
64-
If set, blueprint will create a new instance of nixpkgs for each systems, with the passed config.
65-
66-
Default: `inputs.nixpkgs.legacyPackages.<system>`.
78+
If set, blueprint will create a new overlay with the passed config.
6779

6880
Type: list of functions.
6981

70-
Example:
82+
Here's an example that creates a couple of overlays; the first ("otherflake") reuses an overlay defined in another flake, and the second, an inline overlay, defines an overlay that replaces the default git package with the smaller gitMinimal:
7183

7284
```nix
7385
{

0 commit comments

Comments
 (0)