In reply to @philiptaron:matrix.org

I'm up for a Zoom or other video meetup.

Here's the list of things I'm tracking in stdenv world.

1. __structuredAttrs https://github.com/NixOS/nixpkgs/issues/205690. Mostly driven by @wolfgangwalthier. Thank you!
2. Various improvements to fetchgit,fetchGitHub, etc, mostly around rev vs. tag to increase the expressiveness of the function.
3. Improvements to nixpkgs configuration options to document and regularize those options (https://github.com/NixOS/nixpkgs/pull/330753, but the PR author has left nixpkgs)
4. Structured logging (@nix { "action": "msg", "level": "1", "msg": ...}) support in the stdenv. https://github.com/NixOS/nixpkgs/pull/331794
5. Thorough removal of substituteAll in the nixpkgs codebase: https://github.com/NixOS/nixpkgs/issues/237216
6. Continued progress on clarifying what the environment is and what guarantees are possible across "releases".
7. Linters and checkers (like nixpkgs-vet) that assist with in-tree and out-of-tree users to provide diagnostics and migrations for necessary changes.
8. Breaking apart the knot of bootstrapping on every platform to enable a stdenv that's "bootstrap-free" -- not strangely constrained by bootstrap concerns, but able to be changed without breaking bootstrap.
9. Making sense of how cross-compilation depends and does not depend on stdenv. (This is a personal goal, since I just don't understand it today.)

There are other small things, but this is the majority effort.

In reply to @emilazy:matrix.org
what do you mean by #8?

In reply to @philiptaron:matrix.org
I notice basically everyone who tackles something with bootstrap breaks something. Why? What can we do to make this less common?

In reply to @emilazy:matrix.org
I think things below 18 can go.

In reply to @philiptaron:matrix.org
I notice basically everyone who tackles something with bootstrap breaks something. Why? What can we do to make this less common?

Yes, trofi, exactly this. What we have today works but requires a large seed, is quite entangled with the actual tools themselves, and has pitfalls of many specified and unspecified varieties.

I don't have a vision of my own. I'm just the poor sod in the meme who says we should improve matters somewhat. I hope (at some unspecified future time) to put my labor into trying to define what better looks like and to making it so.

Dealing with circular dependencies seems like a part of shrinking a binary seed though?

Because otherwise you need to include one of the dependencies in the seed.

Isn't this kind of problem exactly why the Guix bootstrap involves multiple versions of GCC?

Obviously, you want to build as few versions as possible and it seems like someone else has already done the hard work of finding a usable path from stage0 to modern GCC.

I suppose the main difficulty is porting the build steps to Nix?

In reply to @trofi:matrix.org
g++ uses libstdc++.so as part of it's implementation. libstdc++ uses g++ to build itself. It's not directly related to the seed. Even after you got the seed you need to build both of those. You need to build both in a single derivation to get them linked against one another (gcc usually builds it in 2 stages internally to untagle from builder's gcc/libstdc++.so, which nixpkgs disables and suffers afterwards, fresh example is https://github.com/NixOS/nixpkgs/issues/342904).