Nix Team Creation • Hacker News Board

Re: Nix Team Creation

#61

Post by rgoulter » Thu, Oct 06, 2022, 2:27 AM UTC

striking wrote: post #47

colinsane wrote: post #41

Earlier quoted context omitted.

> Versioning your features makes them accessible to a wider audience and encourages more risk-averse folks to adopt the features despite the possibility that they may undergo slight changes. just pin the nix package itself and that should ensure the flake API remains consistent for however many months/years you want?

That creates risk when we decide to upgrade, should bugs be fixed or new tools be implemented. Right now we are up to date and hope to keep it that way.

> That creates risk when we decide to upgrade, should bugs be fixed or new tools be implemented.

This is true of literally any dependency, though.

Semver is supposed to grant you confidence that things won't change very much, but it's not a technical guarantee.

In terms of "risk of adopting nix flakes", the lion's share of the risk is in "adopting nix" (because nix is difficult, hard to find people well versed in nix, etc.). The risks from adopting flakes on top of that are marginal.

Re: Nix Team Creation

#62

Post by rgoulter » Thu, Oct 06, 2022, 2:45 AM UTC

outworlder wrote: post #16

My experience with NixOS is: if whatever I want to do is covered by the documentation, I just need to add the necessary enchantments (often verbatim) from the documentation and things _just work_. It certainly takes way less time to do compared to any distribution I've ever used. It's trivial to undo mistakes and I don't have to write down what I did - the code replaces my notes entirely. However, if I can't find wha…

I like to summarise my experience (which resembles yours) as "nix is 95% wonderful, 5% very painful".

> the code replaces my notes entirely.

I think this ends up being one of the key selling points for Nix for developer machines.

Re: Nix Team Creation

#63

Post by zimbatm » Thu, Oct 06, 2022, 10:41 AM UTC

zamalek wrote: post #51

dd_ wrote: post #46

Earlier quoted context omitted.

A few of these problems are fixed with flakes - namely the dramatically improved composability. It becomes much simpler to understand how to use something when you are able to work on it in isolation. With the previous mono-repo nixpkgs assumption, you were basically required to not only learn nix-lang, but also nixpkgs and the nixpkgs workflow making it much harder to grasp the fundamentals. With flakes, it is now s…

I really hope to see a lot of packages move out of nixpkgs, only to be re-imported as flakes. There are currently 3.9k pull requests for nixpkgs; the current model really isn't working.

Look at the ratio instead: 4k open vs 162k closed. Or 4k open vs 80k+ packages.

If we split things up, there will be less open PRs per project of course. But I doubt the ratio will be much better. It will actually increase the number of PRs as large scale refactors will be multiplied by the number of repositories.

Re: Nix Team Creation

#64

Post by thomastjeffery » Thu, Oct 06, 2022, 1:45 PM UTC

rgoulter wrote: post #11

n42 wrote: post #8

Earlier quoted context omitted.

Should I use flakes or not? Every single library I find is a Nix Flake, but insists that Flakes are experimental. Who makes the decision that they are not experimental? At what point does majority adoption of flakes overrule? Why are they still behind a feature flag in the CLI? What is Nickel? Is this an officially endorsed project? It’s run by Tweag — do they run Nix? Most core contributors work for Tweag. What is t…

> Should I use flakes or not? Every single library I find is a Nix Flake, but insists that Flakes are experimental. In this case, "it's experimental" should be read as "maybe the team will decide to make changes", rather than "it's not going to work half the time". e.g. one change they made was changing the property "defaultPackage" to "packages.default". (Anyway, the UX improvements from flakes are good, that once y…

> In this case, "it's experimental" should be read as "maybe the team will decide to make changes", rather than "it's not going to work half the time".

This is exactly the clarification that needs to happen. It hasn't yet, and we've been needing it. That's what I mean by "floundering". Nix isn't broken, but its development progress has been needing explicit direction and clarity.

That's why I'm excited to hear a team is being put together. This is a great opportunity to bring some decisiveness into Nix's development.

Re: Nix Team Creation

#65

Post by Ericson2314 » Thu, Oct 06, 2022, 6:36 PM UTC

pxc wrote: post #49

Smaug123 wrote: post #30

Earlier quoted context omitted.

There was recently a naming rationalisation in which they decided to continue calling everything Nix. ( https://discourse.nixos.org/t/2022-08-25-documentation-team-... )

That's really just a formalization and documentation of the way things are named now. I don't think it precludes renaming some things in the long term.

Yes I discussed with those people while this was happening and it is exactly true.