Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a vision for Nix #7156

Closed
wants to merge 4 commits into from
Closed

Create a vision for Nix #7156

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
8e898ce
Create a roadmap for Nix
thufschmitt Oct 11, 2022
10fe0c3
Update roadmap.md
edolstra Oct 11, 2022
7ecf307
Update roadmap.md
fricklerhandwerk Oct 11, 2022
fcb4da8
Updates from the last Nix team meeting
edolstra Oct 28, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
87 changes: 87 additions & 0 deletions roadmap.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
# Nix is everywhere and invisible
fricklerhandwerk marked this conversation as resolved.
Show resolved Hide resolved

Software developers use Nix as a matter of course every day, mostly without even noticing.
Nix runs trivially, anywhere.
fricklerhandwerk marked this conversation as resolved.
Show resolved Hide resolved
fricklerhandwerk marked this conversation as resolved.
Show resolved Hide resolved

For individuals to large organizations, Nix underpins the the entire software supply chain:
edolstra marked this conversation as resolved.
Show resolved Hide resolved
- Developer tooling
- Build automation
- Binary distribution.

To this end, the Nix team will work towards the following goals.

## Make Nix easy to adopt

- Well-defined target user base
fricklerhandwerk marked this conversation as resolved.
Show resolved Hide resolved
- Well-defined core user stories
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not really clear what the intent of this section is. E.g. we have ad hoc and declarative environments, so we should say here what we actually want to improve about them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of these are better not to be implemented in nix itself, but in places where the ecosystem can iterate on solutions. nix itself should be a source of stability. Places like nixpkgs and other repos are much more suitable for solving open-ended problems because those, unlike nix itself, can be pinned.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also these user stories should be clearly defined so we can prioritise tasks to improve those specifically instead of something else.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should say here what we actually want to improve about them.

I think the point of this item is that we need to know precisely how these can be used to solve concrete problems so that we know how we can meaningfully improve them

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be an acknowledgement that this is at high risk (at least) to contradict the minimisation of opinionated decisions, or some idea how to manage this balance?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is at high risk to contradict the minimisation of opinionated decisions

@7c6f434c what would you charactarise as an opinionated decision in the context of determining first-class user stories? Maybe I'm misunderstanding what you're trying to say.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, drawing a line between first-class and second-class usages is already an opinionated decision, and, for example, the «mass market» user stories probably don't use much package overrides so any story-based redesign will probably impair override facilities. (Without which facilities I probably find Nixpkgs much less useful). And look at unfree-predicate vs flakes to see how well things will go. Another thing is platform support: for first-class user stories you probably say that something either mostly works or not and this fact is recorded in the code base, for exotic cross-compilation with a unique set of tunables things might be broken by upstream changes and patched back to work too often for «broken» in a package to even make sense.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@7c6f434c note that this is only about Nix itself, not Nixpkgs. The user stories would tell what Nix allows immediately, and Nixpkgs would use that for the extended use cases it enables in turn.

And look at unfree-predicate vs flakes to see how well things will go.

What do exactly you mean by that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With non-flake Nixpkgs, you can quickly and easily relax unfree/broken/platform checks for a single invocation. Flakes make it complicated with no clear way how to change Nixpkgs to have the same ease back. It's a Nix change that makes Nixpkgs less useful for some use cases.

- Ad hoc environments
- One-liner setup (nix-shell)
- Declarative environments
- One-liner setup ("templates")
- Easy modification/extension
- Easy and transparent usage ("direnv"/"lorri")
- Secret management as first-class citizen
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Secret management as first-class citizen

Not sure whether this is realistic in the roadmap time frame (except maybe via the ACL work).

Copy link
Contributor

@fricklerhandwerk fricklerhandwerk Oct 11, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a roadmap, this is a set of objectives. It does not have or imply an order or schedule. A roadmap is a sequence of sub-objectives to fulfill in order and may have a schedule.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(eelco): Might be too low-level for the vision
(Robert): The ecosystem already has solutions for that, so probably not mandatory for Nix

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, is there any kind of a principle in the vision what should be allowed to evolve in the ecosystem and what ends up in the core?

Copy link
Contributor

@fricklerhandwerk fricklerhandwerk Nov 4, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ecosystem already has solutions for that, so probably not mandatory for Nix

@robeth Which are those solutions? There was a brief lunch break debate at NixCon that e.g. a primitive in the Nix language for dealing with secret values would be very helpful to enable more sophisticated solutions on top of that.

is there any kind of a principle in the vision what should be allowed to evolve in the ecosystem and what ends up in the core?

@7c6f434c not yet, but I think we absolutely have to answer that question, somehow. For example, it could be implied by the vision statement, i.e. with everything that is not specifically defined by it. In any case we have to make explicit that we draw such a boundary, and make perfectly clear where it is.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What currently says why pinning part of flakes should not be external add-on on equal footing with niv that people used for many of the same aims? I think that any «define basic logic and derive from there» kind of boundary will end up demanding a large redrawing of lines, so you probably need to define at least a process for redrawing the boundary (which Nix currently lacks, judging from NixOS/rfcs#49)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ecosystem already has solutions for that, so probably not mandatory for Nix

@roberth Which are those solutions? There was a brief lunch break debate at NixCon that e.g. a primitive in the Nix language for dealing with secret values would be very helpful to enable more sophisticated solutions on top of that.

Existing solutions: NixOps deployment.keys, sops-nix, agenix.
Potential solutions:

  • NixOS: make NixOps keys part of NixOS. For example nixos-rebuild could take secrets from /root and install them.
  • Nix: extend the string context to allow marking of secret values so that they can not be written to the store.
  • Nix: complicate the store concept. Not a fan of this.

- Configurations as first-class citizens
- Configuration/Modules/Nickel/etc.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Configuration/Modules/Nickel/etc.
- Have everything Nix be configurable, discoverable and introspectable
- Ability to configure arbitrary systems (incl. secrets)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This strikes me as highly ambiguous. What is "everything in Nix" and what does it mean for that to have these properties? Do you mean the source code, or stuff at runtime?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And even at runtime, is it in terms of Nix lib* as a library, or in terms of reflection available to Nix code?

- Language bindings
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Language bindings

Much more important to have JSON output on all relevant commands.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say equally important. A language binding can do strictly more than what JSON output achieves, but JSON is an easier and less invasive interface. We'll need both.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another thing could be implementation-agnostic conformance tests that allow reimplementing things in other languages, if C++ FFI is too hard.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see in the language case this is mentioned below.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The relative importance of goals will be expressed by their ordering in the roadmap. We can say language bindings is something that's part of the vision or not, but will prioritise later.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(roberth): A number of projects rely on or would benefit from unofficial bindings

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Nix side, I think that the important bit would be to provide a stable FFI interface that bindings can build against. Whether the different bindings live inside or outside of the Nix repo is more of a detail imho

- Supply chain trust solution
- Content-addressed derivation
- Build result signing, key distribution
- SBOM/SLSA
- Unprivileged installation and use
<!-- valentin: this needs clarification, I still don't know what rewriting is -->
- Portable store?
- restricted-root
- ACLs
- rewriting
Comment on lines +37 to +42
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be moved to a sub item. The important bit is that Nix runs everywhere

- ...
- Linux, MacOS and Windows support at feature parity
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't think it's realistic to promise this, especially the Windows support.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll want to manage expectations. This isn't quite a roadmap; see https://github.com/NixOS/nix/pull/7156/files#r992369142

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed it is a lot for short term, but excellent for long term.

If get the Meson build system, we can iterate on Windows incrementally I think. E.g., goals like "libnixutil builds on Windows with both MinGW and LLVM in MSVC mode" can be tackled in isolation.

https://github.com/nix-windows/nix after all has things that are too messy right now, but do work. If we pick and choose when tackling those initial goals and clean up, it need not even be that hard.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a promise, but an ambition. The roadmap towards that ambition will be a promise.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Windows is not even a Unix or *nix. Software is often build, distributed and developed very different and a lot of software on Windows is freeware or proprietary especially the entire foundation and core parts. I don't think it is realistic to get nix on feature parity on Windows.


## Make Nix a tool that users can rely on

- Reliable installer
- Effective testing
- Test coverage for all major use cases
- Memory safety validation (sanitizers, ...)
- Benchmarking infrastructure
- Test reports published and accessible
- Executable language specification
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Executable language specification

Sounds like a lot of work for little benefit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least a formal specification would sure be worthwhile.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think tests are actually easier than formal spec. Anyone can submit a test and if it passes CI it is good, but need masters or PhD skills to write a formal language spec.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think @fricklerhandwerk meant to say formal as in formal proof or any other highly technological meaning of formal. Formal can refer to formal language, as in natural language.

I think the other thread about this line illustrates the value of it, which, I agree, is not immediately tangible for users, but is beneficial to the broader community. ("broader community"? Just the fact that such a term is relevant in this context implies that there's work to be done)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly does this mean? Also curious who's working on it, as we're also working on a spec in TVL and it might be useful to collaborate.

Copy link
Member

@roberth roberth Oct 11, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think of it as a literate programming for the test suite. Goals:

  • Improve the test suite
  • Produce a detailed specification document (readable, linkable, etc)
  • Interoperability; allow the test suite to be used in other implementations
  • Potentially, dual-purpose the spec runner as a test framework for Nixlang libraries

I brought this up in the meeting.
We're not in a stage where we're planning implementation time frames and such. I'd describe this document as a detailed mission statement, rather than a roadmap. More on that in a separate thread.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh this is great! I was already talking to @tazjin about these things too. "Literate implementation-agnostic conformance test suite" sounds amazing!!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, it does sound like a good idea but I have my doubts that it will be possible to create a literate spec like that which would also still be something a human would want to read.

Nix language has a huge amount of non-trivial edge cases (many of which are not covered by the C++ Nix test suite, but which have gained tests in Tvix that we run against both our interpreter and C++ Nix). While their behaviour is sometimes straightforward to describe (but not necessarily implement) in "spec-language", actually testing conformance is a verbose affair.

My gut feeling is that rather than trying specifically to make a literate spec, it would be more useful to have a spec and an accompanying conformance test suite (that can be read at one's leisure).

Either way, the hard part of this will be figuring out which things should go in the spec and which things are bugs in C++ Nix. In Tvix, our approach has been to consider "What does nixpkgs do?" as the primary guideline for this, which is the only way we see to actually cut down on some of the stuff that exists in the language. This is also the criteria by which we are working on our spec.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that not all parts of the spec will be fun to read, and the existence of executable test cases in the spec is not excuse not to write the necessary prose that belongs in a spec.

I don't have the illusion that turning a test suite into a literate program automatically creates a good spec, but it does help, and bringing the spec and the conformance suite closer together can only be a good thing. For example, some test cases can be in / near the main prose, whereas others are delegated to a detailed conformance suite section.

Either way, the hard part of this will be figuring out which things should go in the spec and which things are bugs in C++ Nix.

cut down on some of the stuff that exists in the language

I highly value Nix's ability to evaluate old expressions. Without this, what is the point of using Nix for reproducibility long term?

For me the choice seems obvious: put it in the spec. Now I don't have the experience of reimplementing Nix, so I'd like to know what behaviors you've considered to be bugs, but let's save that for later. We could have optional levels of conformance, to accommodate for other projects like Tvix.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I highly value Nix's ability to evaluate old expressions. Without this, what is the point of using Nix for reproducibility long term?

For some behaviours of the C++ evaluator it'd be extremely surprising if you had any expressions depending on it, but unfortunately as an implementor (and doubly so as a spec writer) you need to investigate every little corner (including edge-cases). That means that there's likely some behaviour we can simplify classify as bugs in C++ Nix (and eventually fix) without including them in the spec.

I'd like to know what behaviors you've considered to be bugs, but let's save that for later

We've started a document on our end where we will collect a lot of these things, and we'll also be investigating (or have already done so) each of them to figure out whether expressions in nixpkgs or other large publicly known code-bases (e.g. home-manager, or TVL itself) depend on the behaviour. Note that this is very early form, with some things already added by @sternenseemann but lots of stuff we already know about missing. It might be useful to work on this in a shared Google Doc or similar!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That means that there's likely some behaviour of X we can simplify classify as bugs (and eventually fix) without including them in the spec for X.

I've seen many instances where this principle could be applied. Documenting things with a bit of wishful thinking helps a lot with thinking straight in the first place.


## Make Nix a good investment for users
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the intended meaning of “good investment” needs to be explained given the misunderstandings on that section

Suggested change
## Make Nix a good investment for users
## Make Nix a good investment for users
_Give potential users the assurance that Nix will keep working reliably for them in the long run._

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we want to realize that other than giving our word? Sell service contracts and insurance?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is about the development model, e.g. determining how we deal with deprecation and sticking to that religiously. On the other hand, keeping Nix compatible with its surrounding hardware and software ecosystem, which continues to evolve, is indeed something that needs sustained maintenance.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keeping Nix compatible with ecosystem — would it include accepting a patch with an exploit for PlayStation 3 if somebody had provided it after working on OtherOS support there and Sony fraudulently disabling an advertised feature?


Copy link
Contributor

@fricklerhandwerk fricklerhandwerk Oct 13, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the only way to enable effective development and maintenance to begin with, is to ruthlessly cut scope and abide to the single-responsibility principle. This is what the target audience and user stories play into.

This is to start a more focused discussion on what Nix is supposed to be for:

Suggested change
- Nix is and stays policy-free

That's the best thing we have so far. Nix should be invisible and just work, like plumbing - infrastructure.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this intend to forbid any hardcoded reference to git in flakes code?

- Explicit compatibility guarantees (and non-guarantees)
- Commitment to uncompromising reproducibility
- Well-defined release process
- Feature support status
- Deprecation strategy
- LTS commitments
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure we should commit to this right now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually agree. "LTS" is but a means to an end, the end itself is is "stability policy" or, "support orgs that want to trade new features for more stability".

That Rust has so far gotten away with not having LTSs also makes me think judicious use of experimental features and cross-version testing might actually be sufficient.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already make long term commitments for reproducibility, Nixlang compatibility, a degree of worker protocol compatibility, etc. Have we made those commitments explicit?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dunno about "LTS" in particular, but the whole "compatibility guarantees" is a very important point in my opinion. As @roberth says, we already have most of these implicitly, and it's important to make them explicit so that users know what to expect

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now nixpkgs and so a bit distant also nix is the exact opposite of LTS and I know for a fact that many people I know that use nix choose nix because of the fast development cycle like Arch but with reproducibility and it if it falls apart you can rescue it without a reinstall. Converting nix(pkgs) to LTS would alienate a lot of users.

If LTS means compatibility guarantees (which is not the same thing) then the wording here must be improved.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- LTS commitments
- Compatibility guarantees

- Close Flakes schism, remove uncertanity/ambiguity/confusion

- Exemplary contributor and maintainer experience
- Recommended development setup
- Testing guidance
- Formalize review criteria
- Formalize design criteria (technical invariants)
- Well-defined architecture of isolated components
- Swappable store
- Formalize store protocol
- Swappable Nix language evaluator
- Swappable scheduler and remote-build system
Comment on lines +72 to +75
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

“swappable” might not be the right term here. I don't think we should care too much about it being swappable, but more about having clear and well-defined interfaces (the "swappable" thing can be a side-effect of this, but not the first goal)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Swappable could also be a criterion of this, though.

- Integrate Hydra (modulo UI) into Nix
- Remote protocol speed and reliability improvements
- Binary cache protocol speed improvements
Comment on lines +71 to +78
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Well-defined architecture of isolated components
- Swappable store
- Formalize store protocol
- Swappable Nix language evaluator
- Swappable scheduler and remote-build system
- Integrate Hydra (modulo UI) into Nix
- Remote protocol speed and reliability improvements
- Binary cache protocol speed improvements

This is a lot of work with no benefit to end users.

Copy link
Member

@roberth roberth Oct 11, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

End users are not directly on the receiving end of this section, but by improving our ability to improve the product, we do improve the end user experience long term. (> Exemplary contributor and maintainer experience)

Componentization is good for local reasoning, for testing and it can improve build times.
(For example, having libstore and libexpr as a derivation-level dependencies helps when rebuilding (in Nix) a change to the CLI)
It also fosters other Nix implementation projects and specific use cases. For instance, hnix could more easily talk to the daemon, and an application of Nix in IoT could do store-level update distribution without ever shipping an evaluator to devices.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might not matter to beginners, but it absolutely does matter for end users / institutional users. Maybe chop up the section to indicate that split but please don't drop this!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a lot of work with no benefit to end users

Not true, there are lots of ways in which this is beneficial to end users (this part of the doc is basically the Tvix architecture statement from a while ago, there are reasons people keep converging on these thoughts!).

As a concrete example for an end-user benefit, having pluggable store and substitution implementations lets users adapt to local constraints. If you're in a country like Egypt (where some of us live on and off), using Nix is currently prohibitively expensive due to the huge traffic wasted in central substitution and the price of internet in those countries. Having a switchable implementation there would let us plug in something like a P2P substituting stores with Trustix-verification without impacting the workflows of people that use cache.nixos.org or Cachix through the standard protocols.

Easy to come up with more examples like this for each of the points ... this really is an important topic!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whether (and when) in practice we'll go all the way down there is something for the roadmap (and I tend to agree with Eelco that given the state of things it might be too costly for the short/medium term), but I think that it is a desirable thing, at least as an internal distinction (a stronger one than the libstore/libexpr split which unfortunately has grown to be very leaky and I think isn't modular enough)

Having a switchable implementation there would let us plug in something like a P2P substituting stores with Trustix-verification without impacting the workflows of people that use cache.nixos.org or Cachix through the standard protocols.

Thinking about this (and most of the other use-cases that come to my mind), it feels like the most important part to properly distinguish from the rest (and that's kinda missing here) is an official and properly documented binary cache API. Does that seem right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the binary cache API itself won't be enough here. For example, for p2p substitution you need to solve problems like discovering local chunks, authenticating chunk identity and so on - something like this ("Nix for low external bandwidth") would likely replace the binary cache API completely. That means that what needs to be defined is what the expectations are for "communication" between e.g. eval and the store, or eval and a builder.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thufschmitt I think it is somewhat backwards to think of this as "tool costly". Fixing this is in fact how we pay for things like "Minimal custom code base"; only by cleaning up our own code can we figure out how to slot in off-the-shelf well.

This definitely has benefits on its own, but is is also necessary to tackle other goals without drowning in complexity. Not doing this is more costly if we are to tackle those other goals.

Also agreed with @tazjin. high quality network interfaces, whether for substituting or RPC, leverage domain-specific concerns in lots of ways. The current HTTP interface and the current RPC protocols are equally crummy in this regard.

I will say however that the "having a switchable implementation" would be fine to put under "Minimal custom code base" rather than this. I think that effectively clears up the gaps. The flow of benefits is: good layering -> easy swapping of bespoke current things for external things -> easy to experiment with P2P strategies.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, purely as a user, and assuming only layer separation and not the further development enabled by it, I see layer separation as the only chance to close weird gaps in CLI such as impossible to find in docs (at least to me) operation «.drv + output name → output path» in a systematic way.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we can foster improvements (like already mentioned above) by splicing parts up into smaller pieces I am all for it but we should be careful that we not blindly start and end up with a thousand pieces in the end with no plan or goal and everything just got more complex.

Suggested change
- Well-defined architecture of isolated components
- Swappable store
- Formalize store protocol
- Swappable Nix language evaluator
- Swappable scheduler and remote-build system
- Integrate Hydra (modulo UI) into Nix
- Remote protocol speed and reliability improvements
- Binary cache protocol speed improvements
- Well-defined architecture of isolated components
- Swappable store and formalized store protocol
- Swappable Nix language evaluator
- Swappable remote-build system including it's scheduler

I wouldn't merge hydra in the short term to keep complexity lower and the amount of code lower. Also improvements should go to a different section.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Well-defined architecture of isolated components
- Swappable store
- Formalize store protocol
- Swappable Nix language evaluator
- Swappable scheduler and remote-build system
- Integrate Hydra (modulo UI) into Nix
- Remote protocol speed and reliability improvements
- Binary cache protocol speed improvements
- Well-defined architecture of isolated components
- Swappable store and formalized store protocol
- Swappable Nix language evaluator
- Swappable remote build system and scheduler


- Minimal custom code base (proven off-the-shelf components where possible)
- Git file hashing
- Sandboxing, containers
- Capnproto for RPC
- Bazel RBE protocol
fricklerhandwerk marked this conversation as resolved.
Show resolved Hide resolved
- ...
Comment on lines +80 to +85
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Minimal custom code base (proven off-the-shelf components where possible)
- Git file hashing
- Sandboxing, containers
- Capnproto for RPC
- Bazel RBE protocol
- ...

Likewise this doesn't really fit under "Make Nix a good investment for users".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While the specific points should be subject to debate and were supposed to be random brainstorm ideas, the point here is to reduce maintenance surface. We discussed quite intensely that it needs a lot of deliberation what to depend on and what to purpose-build. But the general idea would be to do things the way outsiders would expect and only customize what is special.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the general idea would be to do things the way outsiders would expect and only customize what is special.

100% agree. I think there's three motivations here:

  • By only focusing on what makes Nix Nix, we can reduce the maintenance burden (with the caveats that we must be very deliberate in choosing what we depend on as Valentin said)
  • By reusing as much as possible off-the-shelf components/standards we remove as much accidental complexity from the face of new users as we can (because although the core of Nix would remain something new to learn, all the stuff around it would potentially be already boring technology). And we send the message that Nix isn't a weird exotic technology, but something firmly grounded in the state-of-the-art technological landscape
  • In terms of pure expressiveness, speaking mainstream protocols means that Nix can integrate with existing tool in a much nicer way. Like what flakes do with the Git repositories for example

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Minimal custom code base (proven off-the-shelf components where possible)
- Git file hashing
- Sandboxing, containers
- Capnproto for RPC
- Bazel RBE protocol
- ...
- Try to use proven off-the-shelf components where possible like already done with:
- editline
- libarchive
- lowdown
- sqlite



<!-- roberth after meeting, feel free to remove when processed: be the binary distribution method of choice for dev tooling, such as IDE plugins that bundle their own binaries (needs Nix (libstore? installer?) to run trivially, anywhere) -->
<!-- valentin: see the top-level goal above, does that match your idea? -->
<!-- valentin: the architectural aspects seem to be dispersed a bit. I still think all the component notes should belong to one goal and rearranged accordingly. -->
fricklerhandwerk marked this conversation as resolved.
Show resolved Hide resolved


"Likewise, we want Nix to be everywhere. We want a world where finding a flake.nix at the root of a software project is not a pleasant surprise but something expected and common. And we want the people who design tomorrow’s software distribution mechanism to at least know and recognize the Nix model, and take that into account."