Round on the current blockers

Debugger PR

Mergeable o/

Some issues with printing potentially large values, but not a blocker

Extra debug info PR

Conflicts with the debugger. Might need to choose one to merge first

• 21:11:07 @edolstra: Maybe the debugger first
• 21:11:21 @layus: Whatever, just choose one
• 21:13:05 @layus: Makes a couple of things uglier. Like NixOS modules who throw an informative error and don't expect to have a stacktrace

Lazy copying of flakes in the store

• 21:14:01 @layus: Really needed by a client
• 21:14:47 @layus: Also annoying because files not tracked by Git aren't tracked properly
• 21:15:15 @garbas: Wouldn't be solved by that (because would still be filtered). But could have a better error message
• 21:15:59 @layus: Wouldn't work for build-time errors though
• 21:16:08 @edolstra: Indeed
• 21:16:54 @layus: Back to lazy loading: Is this going to happen?
• 21:17:23 @edolstra: The PR isn't ready, and probably has a lot of conflicts. But the way to go so will be done at one point
• 21:18:27 Also should be merged at the begining of the merge window
• 21:19:39 @thufschmitt: Could the scope be reduced?
• 21:19:45 @edolstra: Not that much
• 21:20:31 @layus: Need to focus on that. Because it's really important and constantly delayed
• 21:22:00 @thufschmitt: Could be merged incrementally as an xp feature
• 21:22:14 @edolstra: Not really because it's a big change that doesn't just add things
• 21:22:28 @garbas: Maybe could stop merging potentially conflicting PRs (fetchers-related mostly) while it's in the works
• 21:24:15 @garbas: Could be great to have a working version before the next meeting (so make it the big focus for next week)

Taking a step back

• 21:28:02 @thufschmitt: Would be nice to think more “big-picture” during these meetings
• 21:28:21 @garbas: We’d need to do some homework to have a good view of who the users are
• 21:29:15 @edolstra: Could have someone think of a specific topic for each session
• 21:29:36 @garbas: Could base the user thinking in terms of "first steps with Nix"

Things to brainstorm

Per the discussion above, we settled on trying to have one big thing on the agenda for each meeting (in addition to the wip review), and one person doing some preliminary research on it each time to speed things up

For next time

• Sub-flakes (@thufschmitt)

For later

• Flakes-git integration (@layus)
• nix shell semantics (@edolstr, @tomberek)
• Progress bar
• More flexibility in declaring the inputs (@tomberek?)

Who is our audience?

(Quick summary by @garbas):

• Devs (biggest pool of ppl that we can attract)

Two resources to look at:

• First steps with Nix (v1 and v2)
• Guidelines

Documenting the design decisions

• 21:56:26 @layus: It's not clear why Nix does what it does with the git integration
• 21:56:49 @edolstra: (summarizing) it's for hermetic eval
• 21:57:09 @thufschmitt: Can be worked around with path:
• 21:57:19 @layus: Makes sense
• 21:57:25 @garbas: Brings a bigger issue: This kind of design decisions aren't really documented
• 21:57:57 @tomberek: Should we use something like https://adr.github.io/madr/?
• 21:58:55 @layus: I see what problem the flakes-git integration solves, but it's not always convincing for users
• 21:59:35 @garbas: Put that on the agenda for another time?