Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nix Team Creation

discourse.nixos.org

Post reply on HN
Print view View original

11–20 of 65 posts

Re: Nix Team Creation

#11

Post by rgoulter »

n42 wrote: post #8
colordrops wrote: post #4

Earlier quoted context omitted.

Has it been floundering? Could you provide some context?

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 you've got the boilerplate, flakes are amazing).

> Nix is technologically sound but is struggling organizationally from its explosive growth

Well, that's the opposite problem of 'floundering'.

Re: Nix Team Creation

#12

Post by nvln »

n42 wrote: post #8
colordrops wrote: post #4

Earlier quoted context omitted.

Has it been floundering? Could you provide some context?

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…

SEO for Nix is kinda hard unless they decide to change the name. I've resorted to searching github with `extension:nix`, the forum and the manual directly.

Re: Nix Team Creation

#13

Post by biggestlou »

jalino23 wrote: post #5

>> Nix is the cornerstone of the ecosystem I thought Nix is the ecosystem?

In this case, "Nix" refers to the Nix CLI and the Nix language, and not to closely related projects like NixOS, Nixpkgs, Home Manager, and many others that can be understood as "ecosystem" projects dependent on the Nix CLI/language. It's also worth noting that there's a vast constellation of third-party Nix tools that can also be understood as dependent on the core NixOS/nix project on GitHub.

Re: Nix Team Creation

#14

Post by nvln »

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…

> Well, that's the opposite problem of 'floundering'.

+1. The explosive growth has resulted in organic blossoming of several new ideas, approaches and templates. Not all of them are great and it takes time to sift through them to see if there are canonical approaches.

The creation of the team to streamline these ideas, bless some official paths is well timed.

Re: Nix Team Creation

#15

Post by outworlder »

n42 wrote: post #8
colordrops wrote: post #4

Earlier quoted context omitted.

Has it been floundering? Could you provide some context?

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…

> explosive growth

That's the opposite of floundering, no?

Re: Nix Team Creation

#16

Post by outworlder »

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 what I need in the documentation then it can be a problem. That's specially true for installing software. I'm not too familiar with the language to make entire new packages. Most things are using flakes and I haven't wrapped my head around them yet. Other things are not really compatible with its philosophy (like software packaged as Wine bottles).

Nix itself: same problem when the package doesn't exist. But when it does, it's wonderful. I'm even using it in OSX, instead of homebrew (with home-manager).

Hopefully this team will help smooth some of the rough edges.

Re: Nix Team Creation

#17

Post by nonbirithm »

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…

>> 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".

This I think is part of the problem. People see the "experimental" label and don't understand that it's not "experimental" in the sense they're used to. Maybe labeling flakes as a "beta" feature and featuring the documentation more prominently would ease the confusion.

Re: Nix Team Creation

#18

Post by striking »

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".

In that case, I can't in good conscience recommend we use such a feature at my workplace. We can't afford huge breaking changes, which is what that flag suggests. Which means my workplace is stuck with a bunch of `shell.nix` and `direnv` magic instead of clean flake-based envs.

It's not enough to gate features behind a flag, unless your only audience is enthusiasts. 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.

Re: Nix Team Creation

#19

Post by parminya »

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 generally agree that the documentation is a problem. A lot of the code is commented, so if you can find a package in nixpkgs that is using the same language, you can usually do some copypaste, somehow find the function definition it's referencing, and then it's not so hard to make the changes to package your new package. But "somehow find the function definition it's referencing" is not always as easy as it sounds... I think it's the only way to learn though. The documentation just isn't up to the level it needs to be to be self-sufficient.

As for flakes, they're not that big a change. There's some entry point which you have to learn about - a special file (flake.nix) that defines inputs and outputs according to some predefined structure. But the output leafs are just normal nix code - it's just that there's some builtins that can't be used because they do side effects at runtime. But that's less important than it sounds, because if you're using nixpkgs (as a library/input or as a source for copypasting) then it's flake-safe.

Re: Nix Team Creation

#20

Post by callahad »

outworlder wrote: post #15
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…

> explosive growth That's the opposite of floundering, no?

Not necessarily... Nix is compelling enough today that it could experience explosive growth even if core development was completely stuck. If that was the case, newcomers would still find enough value to stick around and spread the word, but existing pain points would go unaddressed.

I'm not close enough to Nix development to know whether this is the case or not in this instance, but the Discourse post makes a compelling argument about pull request statistics. Sibling commenters also point out that flakes have become a de facto standard despite being hidden behind an experimental flag, suggesting that the flag has lingered too long and without clear ownership or authority around stabilizing the feature. That indecision feels like floundering.

Post reply on HN