docs: add basic docs on Tidepool and its package sets #18

Merged
jakehamilton merged 2 commits from KFearsoff/labs:push-wwltzsrwkyqz into main 2025-10-04 20:15:49 +00:00
Contributor

This is very far from perfect, but it lays some groundwork to Tidepool
documentation. This follows my (very limited) understanding, and so is
very much incomplete and WIP. I would like some help with the concepts I
haven't quite understood <3

This is very far from perfect, but it lays some groundwork to Tidepool documentation. This follows my (very limited) understanding, and so is very much incomplete and WIP. I would like some help with the concepts I haven't quite understood <3
KFearsoff added 1 commit 2025-09-08 21:59:17 +00:00
This is very far from perfect, but it lays some groundwork to Tidepool
documentation. This follows my (very limited) understanding, and so is
very much incomplete and WIP. I would like some help with the concepts I
haven't quite understood <3
Irenes reviewed 2025-09-09 06:47:26 +00:00
Irenes left a comment
Owner

seems like a reasonable start to me

seems like a reasonable start to me
@ -0,0 +9,4 @@
to build all other basic Linux utilities, and are often
transitive dependencies of higher-level packages.
The goal of `foundation` is to build `glibc`. For this, a
Owner

well, it builds a whole toolchain, notionally any piece of it could be thought of as the goal.... I think I'd probably say that gcc and glibc are the goals. you need both of them to run C code.

well, it builds a whole toolchain, notionally any piece of it could be thought of as the goal.... I think I'd probably say that gcc and glibc are the goals. you need both of them to run C code.
KFearsoff marked this conversation as resolved
KFearsoff force-pushed push-wwltzsrwkyqz from f6fc5d080f to 5348d37e84 2025-09-11 20:39:06 +00:00 Compare
jakehamilton reviewed 2025-09-11 22:13:55 +00:00
jakehamilton left a comment
Owner

Thank you for putting all of this together!!

Thank you for putting all of this together!!
@ -29,0 +32,4 @@
To build a package, you can run the following command inside of the `tidepool` directory:
```console
nix build -f . packages.foundation.bash.latest
Owner

The default platform set for each package shouldn't be considered stable, it is arbitrary. We should instead be pointing users to <pkg>.packages.<build>.<host>.<target> for now until we have a friendlier interface for consumption.

The default platform set for each package shouldn't be considered stable, it is arbitrary. We should instead be pointing users to `<pkg>.packages.<build>.<host>.<target>` for now until we have a friendlier interface for consumption.
KFearsoff marked this conversation as resolved
@ -29,0 +35,4 @@
nix build -f . packages.foundation.bash.latest
```
If you want to use the flake calling convention, you would have to add `package` attribute:
Owner

We should probably just specify .package all the time to avoid ambiguity.

We should probably just specify `.package` all the time to avoid ambiguity.
KFearsoff marked this conversation as resolved
@ -29,0 +49,4 @@
This attrpath sets up default platforms for you. You can also set platforms explicitly, with this syntax:
```console
nix build .#packages.foundation.gcc.latest.packages.<build>.<host>.<target>.package
Owner

I think this is what we should be showing the user for building packages right now.

I think this is what we should be showing the user for building packages right now.
KFearsoff marked this conversation as resolved
@ -29,0 +70,4 @@
## Development
Tidepool is built with Aux's portable submodules. They function similarly to NixOS modules.
Owner

They function similarly to normal submodules.

They function similarly to normal submodules.
KFearsoff marked this conversation as resolved
@ -29,0 +73,4 @@
Tidepool is built with Aux's portable submodules. They function similarly to NixOS modules.
Using the submodules, Tidepool provides a nice and easy-to-work-with API.
Tidepool can be used with flakes or without them (using [npins](https://github.com/andir/npins)).
Owner

Maybe we can reword this. Npins is one solution for fetching Tidepool, but there are others.

Maybe we can reword this. Npins is one solution for fetching Tidepool, but there are others.
KFearsoff marked this conversation as resolved
@ -29,0 +75,4 @@
Tidepool can be used with flakes or without them (using [npins](https://github.com/andir/npins)).
Tidepool exports an attribute set, which can be viewed using `nix repl`. Let's visualize
it using `nix flake show` and see what is there!
Owner

We shouldn't mention nix flake show here, none of our stuff conforms to the flake schema and it can fail with an error in some cases.

We shouldn't mention `nix flake show` here, none of our stuff conforms to the flake schema and it can fail with an error in some cases.
KFearsoff marked this conversation as resolved
@ -29,0 +129,4 @@
- `internal` - this is the internal attribute set. Currently, it only brings Tidepool's
dependencies into scope: more concretely, it exposes the `foundation` namespace from
a confusingly-named [Foundation](https://git.auxolotl.org/auxolotl/foundation) repository,
Owner

Perhaps we can remove "confusingly named"?

Perhaps we can remove "confusingly named"?
Author
Contributor

Well... I think it is confusingly named! Having a repo named Tidepool and also a package set named tidepool that uses the Tidepool repo is plenty confusing.

Well... I think it is confusingly named! Having a repo named Tidepool and also a package set named `tidepool` that uses the Tidepool repo is plenty confusing.
Member

I think I'd prefer to say that it might be confusing (because I agree), but also clarify the difference: it's used to bring in packages from the "Foundation" package set (which is our early bootstrap), which is not the same as the foundation namespace inside "Tidepool" (which makes those early-bootstrap packages play nice within tidepool, notably by allowing cross-compilation).

I think it would feel better than to say "it's confusing ! awkward silence ... good luck !" (obv hyperbole, but I hope I'm clear ^^)

I think I'd prefer to say that it might be confusing (because I agree), but also clarify the difference: it's used to bring in packages from the "Foundation" package set (which is our early bootstrap), which is not the same as the `foundation` namespace inside "Tidepool" (which makes those early-bootstrap packages play nice within tidepool, notably by allowing cross-compilation). I think it would feel better than to say "it's confusing ! *awkward silence* ... good luck !" (obv hyperbole, but I hope I'm clear ^^)
KFearsoff marked this conversation as resolved
@ -29,0 +131,4 @@
dependencies into scope: more concretely, it exposes the `foundation` namespace from
a confusingly-named [Foundation](https://git.auxolotl.org/auxolotl/foundation) repository,
which does the bootstrap chain from a 357-byte file
- `new` - this is a function that allows to create a new package set, independent
Owner

Rather than saying "independent from Tidepool", maybe we can say "a new empty package set".

Rather than saying "independent from Tidepool", maybe we can say "a new empty package set".
KFearsoff marked this conversation as resolved
@ -29,0 +149,4 @@
tidepool.new module;
```
- `preferences` - this is an attribute set that lists your current preferences.
Owner

Rather than "current preferences" let's say "preferences for the package set".

Rather than "current preferences" let's say "preferences for the package set".
KFearsoff marked this conversation as resolved
@ -0,0 +4,4 @@
## Foundation
`foundation` is a package set similar to Nixpkgs' `stdenv`.
Owner

I don't think this is equivalent to stdenv. Stdenv does a lot of other things. Rather, this is a minimal set of packages made available for all platforms to begin building off of.

I don't think this is equivalent to stdenv. Stdenv does a lot of other things. Rather, this is a minimal set of packages made available for all platforms to begin building off of.
KFearsoff marked this conversation as resolved
@ -0,0 +9,4 @@
to build all other basic Linux utilities, and are often
transitive dependencies of higher-level packages.
The goal of `foundation` is to build a GNU C toolchain.
Owner

Slight tweak, the goal is to provide a working GCC and associated tools so other packages can be built with them.

Slight tweak, the goal is to provide a working GCC and associated tools so other packages can be built with them.
KFearsoff marked this conversation as resolved
@ -0,0 +25,4 @@
Neat!
The bootstrap chain is based on [full-source](https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/)
bootstrap, made possible with amazing work by Guix's people!
Owner

Don't forget the work Emily Trau did bringing it to Nix.

Don't forget the work Emily Trau did bringing it to Nix.
KFearsoff marked this conversation as resolved
@ -0,0 +33,4 @@
To build stage1 (`i686-linux`), run:
```console
nix build --system i686-linux .#packages.foundation.glibc.versions."2.38-stage1-passthrough".package
Owner

We should be specifying the fully qualified build/host/target to get the right package for consistency.

We should be specifying the fully qualified build/host/target to get the right package for consistency.
KFearsoff marked this conversation as resolved
@ -0,0 +57,4 @@
It's worth discussing this in more depth, because it demonstrates a couple of
more advanced features.
`context` is a special option that announces information that is needed to
Owner

Context is information that this package provides when it is used as a dependency. Builders and hooks may use that context as they wish.

Context is information that this package provides when it is used as a dependency. Builders and hooks may use that context as they wish.
KFearsoff marked this conversation as resolved
@ -0,0 +60,4 @@
`context` is a special option that announces information that is needed to
use the package as a dependency. For example, to use a C dependency, you
would need to tell the compiler where to look for relevant headers by appending
a flag. The C dependency can have `context` defined which includes the necessary
Owner

We probably don't want to lock this down just yet, context is going to change a fair bit.

We probably don't want to lock this down just yet, context is going to change a fair bit.
Author
Contributor

I think we can have it there for the time being. Going further, I would like to split up this README into smaller pieces of relevant info, so when context changes, it will be easy to edit information about it.

I think we can have it there for the time being. Going further, I would like to split up this README into smaller pieces of relevant info, so when `context` changes, it will be easy to edit information about it.
Member

I agree with KFears, I think we should still explain what context does right now. context will change, but in the meantime I suspect a few people will be curious about tidepool's architecture and this explanation is still valuable imo.

It might be worth adding a note that, while all of tidepool is subject to change, context is for sure going to, so this information might not stay relevant very long.

I agree with KFears, I think we should still explain what `context` does right now. `context` will change, but in the meantime I suspect a few people will be curious about tidepool's architecture and this explanation is still valuable imo. It might be worth adding a note that, while all of tidepool is subject to change, `context` is for sure going to, so this information might not stay relevant very long.
KFearsoff marked this conversation as resolved
KFearsoff force-pushed push-wwltzsrwkyqz from 5348d37e84 to 6293761554 2025-09-13 21:00:09 +00:00 Compare
austreelis requested changes 2025-10-04 11:53:05 +00:00
austreelis left a comment
Member

Thanks for the work, it's looking good to me ! I just have essentially two points:

  • I'd prefer we don't rely on people having the experimental cli enabled. I know it's very common, but it's not 100% guaranteed while the v1 cli is always available. I don't think that not relying on it isn't not assisting users that will probably be more used to cli v3, I'm not saying we shouldn't ever mention it. Just that if we're not talking about it and showing something that can be done just as easily with cli v1, I think we should.
  • Some clarifications/disambiguation that caught my eye while reading through
Thanks for the work, it's looking good to me ! I just have essentially two points: - I'd prefer we don't rely on people having the experimental cli enabled. I know it's very common, but it's not 100% guaranteed while the v1 cli is always available. I don't think that not relying on it isn't not assisting users that will probably be more used to cli v3, I'm not saying we shouldn't ever mention it. Just that if we're not talking about it and showing something that can be done just as easily with cli v1, I think we should. - Some clarifications/disambiguation that caught my eye while reading through
@ -29,0 +32,4 @@
To build a package, you can run the following command inside of the `tidepool` directory:
```console
nix build -f . packages.foundation.bash.latest.packages.x86_64-linux.x86_64-linux.x86_64-linux.package
Member

I think we should not default to the cli-v3 commands in docs. I get what I'm saying may be a hot take, but: it's still an experimental feature. There are strictly less people that can run this command instead of the one that is not experimental, hence why I think this should be:

nix-build -A packages.foundation.bash.latest.packages.x86_64-linux.x86_64-linux.x86_64-linux.package

(I'll use that command for my other comments, but won't repeat that point)

PS: ofc we should use the flake syntax and experimental commands when talking about the flake specifically :P

I think we should not default to the cli-v3 commands in docs. I get what I'm saying may be a hot take, but: it's still an experimental feature. There are strictly less people that can run this command instead of the one that is not experimental, hence why I think this should be: `nix-build -A packages.foundation.bash.latest.packages.x86_64-linux.x86_64-linux.x86_64-linux.package` (I'll use that command for my other comments, but won't repeat that point) PS: ofc we should use the flake syntax and experimental commands when talking about the flake specifically :P
KFearsoff marked this conversation as resolved
@ -29,0 +46,4 @@
The full command syntax looks like this:
```console
nix build .#packages.<package set>.<package>.<version>.packages.<build>.<host>.<target>.package
Member

I think we should use a nix-native syntax that is actually legal and can actually be used for this:

- nix build .#packages.<package set>.<package>.<version>.packages.<build>.<host>.<target>.package
+ nix-build -A packages.${package-set}.${package}.${version}.packages.${build}.${host}.${target}.package

Especially given that <stuff> is actual nix syntax.

I think we should use a nix-native syntax that is actually legal and can actually be used for this: ```patch - nix build .#packages.<package set>.<package>.<version>.packages.<build>.<host>.<target>.package + nix-build -A packages.${package-set}.${package}.${version}.packages.${build}.${host}.${target}.package ``` Especially given that `<stuff>` is actual nix syntax.
KFearsoff marked this conversation as resolved
@ -29,0 +49,4 @@
nix build .#packages.<package set>.<package>.<version>.packages.<build>.<host>.<target>.package
```
It allows you to specify many things! For example, you can specify the package version:
Member

The transition here is a bit quick imo, we should tell that above this, version is one of "latest" or "stable", and because it's an alias for an actual fixed version, it goes under ${package}.${version}.

But you can access actual fixed versions as below, like "5.2.15-stage1" using ${package}.versions.${version}.

The transition here is a bit quick imo, we should tell that above this, `version` is one of `"latest"` or `"stable"`, and because it's an alias for an actual fixed version, it goes under `${package}.${version}`. But you can access actual fixed versions as below, like `"5.2.15-stage1"` using `${package}.versions.${version}`.
KFearsoff marked this conversation as resolved
@ -29,0 +89,4 @@
We can visualize it!
```console
git+file:///home/nixchad/Documents/Projects/labs?dir=tidepool
Member

I don't like the subtle reference to "chad", that's a far-right meme that originated on 4chan. If we do show the output of nixflake show, we should use the flakeref git+https://git.auxolotl.org/auxolotl/labs?dir=tidepool, that won't leak anyone's home dir nor require us to invent weird pseudonyms :P

I don't like the subtle reference to "chad", that's a far-right meme that originated on 4chan. If we do show the output of `nixflake show`, we should use the flakeref `git+https://git.auxolotl.org/auxolotl/labs?dir=tidepool`, that won't leak anyone's home dir nor require us to invent weird pseudonyms :P
KFearsoff marked this conversation as resolved
@ -29,0 +108,4 @@
│ ├───...
│ └───zlib omitted (use '--all-systems' to show)
└───preferences: unknown
```
Member

This nix flake show output is confusing imo. Because tidepool does not comply to flakes schema, it will either add those omitted (use '--all-systems' to show) or fail if you do give --all-system:

git+https://git.auxolotl.org/auxolotl/labs?dir=tidepool
├───builders: unknown
├───extend: unknown
├───internal: unknown
├───lib: unknown
├───mirrors: unknown
├───new: unknown
├───packages
│   ├───aux
error: expected a derivation

So I'd actually just show a very generic tree that's not obviously coming from nix flake show, also with a better ordering (imo):

tidepool
├───builders
├───lib
├───mirrors
├───packages
│   ├───aux
│   │   ├───a
│   │   ├───b
│   │   └───c
│   ├───foundation
│   │   ├───bash
│   │   ├─── ...
│   │   └───zlib
│   ├───context
│   │   └─── ...
│   └───...
├───extend
├───internal
├───new
└───preferences
This `nix flake show` output is confusing imo. Because tidepool does not comply to flakes schema, it will either add those `omitted (use '--all-systems' to show)` or fail if you do give `--all-system`: ```console git+https://git.auxolotl.org/auxolotl/labs?dir=tidepool ├───builders: unknown ├───extend: unknown ├───internal: unknown ├───lib: unknown ├───mirrors: unknown ├───new: unknown ├───packages │ ├───aux error: expected a derivation ``` So I'd actually just show a very generic tree that's not obviously coming from `nix flake show`, also with a better ordering (imo): ``` tidepool ├───builders ├───lib ├───mirrors ├───packages │ ├───aux │ │ ├───a │ │ ├───b │ │ └───c │ ├───foundation │ │ ├───bash │ │ ├─── ... │ │ └───zlib │ ├───context │ │ └─── ... │ └───... ├───extend ├───internal ├───new └───preferences ```
KFearsoff marked this conversation as resolved
@ -0,0 +4,4 @@
## Foundation
`foundation` is a minimal package set to start building everything else.
Member
- `foundation` is a minimal package set to start building everything else.
+ The package set under `foundation` is a minimal set to start building everything else.
+ It builds upon and uses packages from [Foundation](https://git.auxolotl.org/auxolotl/foundation), our early bootstrap.

I think this will help clarify the difference.

```patch - `foundation` is a minimal package set to start building everything else. + The package set under `foundation` is a minimal set to start building everything else. + It builds upon and uses packages from [Foundation](https://git.auxolotl.org/auxolotl/foundation), our early bootstrap. ``` I think this will help clarify the difference.
KFearsoff marked this conversation as resolved
KFearsoff added 1 commit 2025-10-04 18:55:21 +00:00
requested review from austreelis 2025-10-04 18:56:15 +00:00
Author
Contributor

Feedback addressed!

Feedback addressed!
jakehamilton approved these changes 2025-10-04 20:15:42 +00:00
jakehamilton left a comment
Owner

Thank you!!

Thank you!!
jakehamilton merged commit 02a45110c9 into main 2025-10-04 20:15:49 +00:00
jakehamilton deleted branch push-wwltzsrwkyqz 2025-10-04 20:15:51 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: auxolotl/labs#18
No description provided.