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

21–30 of 65 posts

Re: Nix Team Creation

#21

Post by parminya »

nonbirithm wrote: post #17
rgoulter wrote: post #11

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

Even better would be just committing to what's there - it's so widely deployed that it's not seriously problematic. It's there to be used.

Re: Nix Team Creation

#22

Post by hakre »

striking wrote: post #18
rgoulter wrote: post #11

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. 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-b…

AFAIK you don't have to use flakes. Same as it's fine to only use shell.nix. No system is for eternity, nix builds are deterministically cached, often never reproduced, so I see no strong arguments against using direnv with shell.nix.

Re: Nix Team Creation

#23

Post by hakre »

nonbirithm wrote: post #17
rgoulter wrote: post #11

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

Perhaps the script is missing that declares what is undefined behaviour in flakes.

Re: Nix Team Creation

#24

Post by colordrops »

parminya wrote: post #21
nonbirithm wrote: post #17

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

Even better would be just committing to what's there - it's so widely deployed that it's not seriously problematic. It's there to be used.

Agreed, they should just bite the bullet and commit to flakes as enabled and not "experimental". There are plenty of other things that break regularly with my nix deployment and it's never flakes.

Re: Nix Team Creation

#26

Post by abathur »

rgoulter wrote: post #9
colordrops wrote: post #4

Earlier quoted context omitted.

Has it been floundering? Could you provide some context?

I'm not aware of context, but looking at the latest release seems to have fewer changes compared to the releases before it. https://nixos.org/manual/nix/stable/release-notes/rl-2.11.ht...

To ~rectify some problems caused by the really large gap between the release of 2.3 and the next minor/major, the release of Nix 2.4 in November 2021 marked a move to a 6-week release cadence. Since they're driven by a calendar now, some will inevitably be bigger/smaller.

Re: Nix Team Creation

#27

Post by aidenn0 »

parminya wrote: post #19
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.…

This is generally true, but I have yet to successfully make a nix overlay for any haskell package not already in nixpkgs. I can't make heads-nor-tails of how the haskell packaging works, other than forking nixpkgs and rerunning the scripts that generate the packages from cabal.

Re: Nix Team Creation

#28

Post by kaba0 »

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…

> like software packaged as Wine bottles

I always wondered why there are no wine packages using nix. Sure, it is likely not legal, but I would absolutely love to have an MS office package that mandates a specific hashed file (that I can torrent and add to the nix store - this way I don’t even risk viruses), and the install itself is deterministically done (perhaps with some headless GUI clicking here and there).

Re: Nix Team Creation

#29

Post by sterlind »

thomastjeffery wrote: post #2

Good news. Nix has really been floundering lately. It needs some assertive direction.

despite the shortcomings and ambition of Nix, I've been amazed at how it's catching on. I see shell.nix files in tons of mainstream projects now, or Nix used to set up CI environments or package projects.

it gives me hope. I just wish the boilerplate were less arcane. Nix is a relatively elegant language, I'm not sure why nixpkgs is so ugly.

Re: Nix Team Creation

#30

Post by Smaug123 »

Ericson2314 wrote: post #7
jalino23 wrote: post #5

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

Hopefully some things get renamed eventually!

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-...)
Post reply on HN