# 2022-10-19 Nixpkgs Architecture Team Meeting #14

**URL:** https://discourse.nixos.org/t/2022-10-19-nixpkgs-architecture-team-meeting-14/22578
**Category:** Nixpkgs Architecture
**Created:** [October 18, 2022, 5:27pm UTC](https://discourse.nixos.org/t/2022-10-19-nixpkgs-architecture-team-meeting-14/22578 "2022-10-18T17:27:54Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![Infinisil](https://discourse.nixos.org/user_avatar/discourse.nixos.org/infinisil/32/26523_2.png) [@Infinisil](https://discourse.nixos.org/u/Infinisil)
#### Post date: [October 18, 2022, 5:27pm UTC](https://discourse.nixos.org/t/2022-10-19-nixpkgs-architecture-team-meeting-14/22578/1 "2022-10-18T17:27:54Z")

</div>

The NAT is there to solve architectural nixpkgs issues that are too big in scope for any single person to undertake. There are regular 30 minute [meetings](https://github.com/nixpkgs-architecture#meetings) every week (currently 13:30 to 14:00 UTC) in [Jitsi Meet](https://meet.jit.si/nixpkgs-architecture), open for anybody to join, recorded and live-streamed [to YouTube](https://www.youtube.com/channel/UC_BFweJOiukTHdKCr1P0kRQ), meeting notes are [public](https://github.com/nixpkgs-architecture/meetings).

The agenda for the NAT is generally created from discussions in the past week, mostly [on Matrix](https://matrix.to/#/#nixpkgs-architecture:nixos.org), but you’re also free and encouraged to suggest additional topics by replying to this thread.

## Tentative Agenda

### Spack: External dependencies and specifications

@tgamblin, the lead of the [Spack](https://spack.io/) project [talked a bit](https://matrix.to/#/!djTaTBQyWEPRQxrPTb:nixos.org/$BqBuWyI1_QdU-B9tEqN0HqciRqzUCBER3G1x-C-jWeQ?via=nixos.org&via=matrix.org&via=nixos.dev) about how Spack works, especially regarding [external packages](https://spack.readthedocs.io/en/latest/build_settings.html#external-packages) and its [specifications](https://spack.readthedocs.io/en/latest/basic_usage.html#specs-dependencies) to resolve package versions and dependencies. Spack notably uses [answer set programming](https://en.wikipedia.org/wiki/Answer_set_programming) instead of a [SAT solver](https://en.wikipedia.org/wiki/SAT_solver) for this. A [new paper](https://arxiv.org/abs/2210.08404) by @tgamblin and others goes into this. Spack uses [clingo](https://github.com/potassco/clingo) to solve [this logic program](https://github.com/spack/spack/blob/1ae32ff62c0827e3cc6150e1127cab91be694c91/lib/spack/spack/solver/concretize.lp).

Others involved in the discussion were @toonn, @Growpotkin (who wrote [an STM solver in Nix](https://github.com/aakropotkin/ak-nix/blob/28a4488e77dfcf7b7a62e10ce4a67ca17c6f18ba/lib/semver.nix)!), @danielbarter, @ronnypfannschmidt:matrix.org  
(don’t know if they’re on Discourse)

#### Deep runtime dependency substitution

Nix currently doesn’t have a good way of substituting deep runtime dependencies, which Spack does and would be useful in a number of use cases. A [NAT wiki article](https://github.com/nixpkgs-architecture/issues/wiki/Deep-runtime-dependency-substitutions) on this has been created, and a number of solutions have been proposed after the previous meeting by @Infinisil, @ronnypfannschmidt:matrix.org, @Growpotkin and @Ericson2314. I encourage you to update the wiki article to briefly explain your ideas there.

### The Nixpkgs Architecture Team is on [nixos.org](http://nixos.org) now

In [a PR](https://github.com/NixOS/nixos-homepage/pull/907) to the [nixos.org](http://nixos.org) homepage, a section about the NAT was added to the website: [https://nixos.org/community/teams/nixpkgs-architecture.html](https://nixos.org/community/teams/nixpkgs-architecture.html). Now duplicated on the website, the information can be removed from the original team page in [another PR](https://github.com/nixpkgs-architecture/.github/pull/4).

### Problems with RFC 127

[RFC 127](https://github.com/NixOS/rfcs/pull/127) is in the [FCP](https://github.com/NixOS/rfcs#final-comment-period-fcp) now, though @Infinisil is not happy with it as it seems to make deprecations throw errors immediately without warning for a release.

### JSON schema for NixOS options

@Profpatsch proposed to have a JSON schema for NixOS options, which would allow them to be written with auto-completion in a JSON file. @DavHau, @nbp, @whentze and @piegames were also involved in the discussion

## Active RFC drafts

In addition to the agenda, this post can bring attention to the existing RFC drafts of the NAT. Feel free to open issues/PRs in these repositories if you want to bring something to attention relating to that RFC draft. Alternatively feel free to [chat on Matrix](https://matrix.to/#/#nixpkgs-architecture:nixos.org) or reply here on Discourse.

- [Auto-called packages](https://github.com/nixpkgs-architecture/auto-called-packages): Make most attribute definitions in `pkgs/top-level/all-packages.nix` be auto-generated from a single flat (or prefixed) directory instead, where the subdirectory corresponds to the attribute name. The ad-hoc category-based structure of packages will be removed.

---

<div class="post-metadata">

### Author: ![toraritte](https://discourse.nixos.org/user_avatar/discourse.nixos.org/toraritte/32/6777_2.png) [@toraritte](https://discourse.nixos.org/u/toraritte)
#### Post date: [October 18, 2022, 7:37pm UTC](https://discourse.nixos.org/t/2022-10-19-nixpkgs-architecture-team-meeting-14/22578/2 "2022-10-18T19:37:25Z")

</div>

Linking: [Nix vs Spack why one or the other?](https://discourse.nixos.org/t/nix-vs-spack-why-one-or-the-other/3496)  
There is also the [`flatironinstitute/nixpack`](https://github.com/flatironinstitute/nixpack) project (where “_nixpack = nix+spack_”)

---

<div class="post-metadata">

### Author: ![Infinisil](https://discourse.nixos.org/user_avatar/discourse.nixos.org/infinisil/32/26523_2.png) [@Infinisil](https://discourse.nixos.org/u/Infinisil)
#### Post date: [October 22, 2022, 10:33am UTC](https://discourse.nixos.org/t/2022-10-19-nixpkgs-architecture-team-meeting-14/22578/3 "2022-10-22T10:33:07Z")

</div>

# Meeting notes

## Protocol

- [Recording](https://youtu.be/E5AyHPIli4Y)
- [Matrix announcement](https://matrix.to/#/!djTaTBQyWEPRQxrPTb:nixos.org/$qTtZmx6QA8hu1ho6E3bbwbngtpZaWXEyuh11nTJcWN0?via=nixos.org&via=matrix.org&via=nixos.dev)
- Who records: @infinisil
- Who leads the meeting: @infinisil
- Who takes meeting notes: @infinisil

## Notes

### Spack: External dependencies and specifications

Notes:

- @tgamblin: Still a SAT solver
  - But specification and optimization is simpler
  - ASP works really well for us

- @tgamblin: Another idea is Z3, SMT
  - Seems harder to specify

- @tgamblin: externals aren’t as pure as you’d like
  - Specifying dependencies, build options etc.
  - Could get incompatible upgrade

- @tgamblin: Main thing about the paper is reusing built binaries
  - If you have a minor tweak, tries to reuse already existing binaries
  - Spack knows about which binaries are available cached
  - Another purity thing we’re planning to do: Currently can’t build on one version, deploy for another. Things like ABI compatibility.
  - Stub symbols sounds similar to something we’ve done. There’s abstract and concrete specs, only give requirements during abstract specs, certain flags. Should only deploy with libraries that fulfil the spec
  - Don’t recommend writing own solver

- @nbp: Alternative to SAT solver: Nixpkgs doesn’t need one as we’re baking one solution. Same for updating dependencies, security updates PR [Shipping Security Updates by nbp · Pull Request #10851 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/pull/10851)
  - @nbp: Not that complicated, but hard to integrate into nixpkgs
  - SOS ([https://github.com/NixOS/rfcs/pull/3](https://github.com/NixOS/rfcs/pull/3)) would make makes this a lot simpler
  - @tgamblin: Resolver is there because packages typically aren’t written with specific versions, but rather with bounds. Those are preserved and are given to the solver. Can work with existing binaries and external packages. ABI compatibity with the shipping security updates PR
  - @nbp: Up to submitter to ensure compatibility. Generally not our problem.
  - @nbp: Always building latest package. With CV change applied to another, building one latest version for base, one with it applied
  - @tgamblin: Currently struggling with ABI incompatibilities.
  - @infinisil: Nixpkgs can always use the latest version, authorative, single CI. With flakes people want more distributed Nix expressions and dependencies, version requirements come up more.
  - @tgamblin: Environments remind me a bit of flakes

#### Deep runtime dependency substitution

### The Nixpkgs Architecture Team is on [nixos.org](http://nixos.org) now

### Problems with RFC 127

### JSON schema for NixOS options
