---
title: Nix UX meeting 2022-06-30
tags: meeting, nix_ux
date: 2022-06-30
breaks: false
---

Attendees: @unwhgw-2SOWNaBf6c6k6jg @layus @bKTAyiAjR4COcXhZNHJF_g @regnat [@infinisil](https://github.com/infinisil/)

# Round on the current issues to discuss

## `builtins.debug`

<https://github.com/NixOS/nix/pull/4914>

Everything good on the design part. Just need the author (or someone else) to fix the CI failure.

## Flake inputs propagation

Mostly <https://github.com/NixOS/nix/issues/6549> and <https://github.com/NixOS/nix/pull/6550>

Overall good, but we need a good solution for deciding what such a `.register` (or however you name it) will override.
The current solution of “just override anything that's not explicitly defined” isn't really satisfying.

Better solution: As suggested in <https://github.com/NixOS/nix/pull/6550#issuecomment-1144635004>, have an extra input attribute in the input telling whether it should be overriden by something like `.register`
- We didn't decide on the default value for this. I (@regnat) would favor no overriding by default to stay on the safe side, but not sure it's the wisest

A conceptual issue with this is that it makes the name of the inputs meaningful (while they're only opaque identifiers right now). But there doesn't seem to be a good solution to that problem.

Comparison with other solutions:
- Bazel has this “one version of each dependency” policy for the rules sets, with no version management at all, which seems to work OK for them. But they also tend to have a pretty shallow dependency tree, so there's not too many conflicting constraints to satisfy
- Language package-managers generally have a way to define version constraints and a SAT solver to find a working dependency plan
- We could have that in Nix, but that's a big undertaking
- Just defining a notion of “versions” would be non-trivial, and probably too much for Nix 3.0
- Aside: “pluggable flake resolvers”
- We could support having an external program to do the resolving for us
- That would allow some fanciers dependency resolution mechanisms in some contexts where it makes sense
- For example a language-specific package manager that would want to use Nix as a backend

@bKTAyiAjR4COcXhZNHJF_g has an had-hoc workaround for the problem (in the case of multi-flake repos) involving generating a sub-flake with the right dependency set

## `nix flake update` vs `nix flake lock --update-input foo`

<https://github.com/NixOS/nix/issues/5110>

Confusion as the two commands do something very similar (but are a different commands)

For all intents and purposes, `nix flake update` is an alias of `nix flake lock --recreate-lockfile`. Maybe we could just state that explicitely in the doc to reduce the confusion

## `dir` query parameter in `path:` flakerefs

Flakerefs of the form `path:/foo/bar?dir=blah` don't seem to work.

These might have a different semantics than `path:/foo/bar/blah` wrt. subflakes (they might no atm, but will definitely with <https://github.com/NixOS/nix/pull/6530>).

In theory that should work, need to investigate why it doesn't. And check that it's still the case with #6530 and write a proper issue about if it is

## Invert the `system` and “field type” argument in the flake hierarchy

Why do we have `blah.${system}` and not `${system}.blah`?

Mainly because of the mix between system-dependant and system-agnostic outputs: We don't want the toplevel attribute to contain both system names and toplevel attr names

## Remote breakpoint hook

Would be great to have a native story for <https://nixos.org/manual/nixpkgs/stable/#breakpointhook>
- Shouldn't need any specific setup
- Should work with remote builders too
- Should work with MacOS
- Mac doesn't have namespaces so the mechanism would be different ofc, but that shouldn't be a fundamental issue

# Agenda for the day

Progress-bar by @garbas, but he couldn't make it to the meeting