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

51–60 of 65 posts

Re: Nix Team Creation

#51

Post by zamalek »

dd_ wrote: post #46
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…

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.

Re: Nix Team Creation

#52

Post by dd_ »

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.

I don't know if packages should necessarily be moved out of nixpkgs since I doubt most people who don't use nix would want to maintain flake.nix in their project, nor would users want to have 30+ flakes in their inputs. However, I can see a good case for separating the package definitions from the nixos modules and the stdlib (mkDerivation, stdenv, etc). Maybe there could be a flake for each.

As for keeping up with PRs and other responsibilities, that seems to be one of the stated goals of the this new Nix Team. I guess we'll see how they intend to handle this soon.

Re: Nix Team Creation

#53

Post by uncletaco »

nonbirithm wrote: post #3

I'm glad this is happening. I was hoping that maybe the Nix/NixOS developers could have a dedicated documentation maintainer or two to make deeper learning about each system more accessible. Although I can make my way around NixOS, I feel that's only possible because I could look over the obscure parts of the configs of people more obsessed with Nix than me. The old development style mentioned reminds me of that exce…

About 80% of Henrik Lissner's fame is Doom Emacs. The other 20% is his Nix config that people clone and then show up in the doom discord asking why their computer won't log in anymore.

Re: Nix Team Creation

#54

Post by est31 »

eptcyka wrote: post #31
kaba0 wrote: post #28

Earlier quoted context omitted.

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

Windows application installers generally are just binary blobs that can do as they please, so just pinning an installer will not imply that the resulting installation will be deterministic - a lot of installers by design change the global state of the system and download stuff during the installation process. If you want packaged on Windows, try choco. Edit: fixing autocorrect typos.

You are right in the first approximation, windows application installers can do whatever they want. However, many applications work already if you extract the files from the installer and put them into the appropriate directories, which you can make a deterministic process. There are tools for this, e.g. msiextract.

Re: Nix Team Creation

#55

Post by tomberek »

outworlder wrote: post #6
jalino23 wrote: post #5

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

Nix vs NixOS?

Nix is the package manager that works on a multitude of operating systems. Then there was the thought “what if we use this same underlying technology to make a Linux distribution” and “we can manage services in a declarative manner” which became NixOS.

Re: Nix Team Creation

#56

Post by rowanG077 »

amelius wrote: post #33

I'm trying to get Nix to compile software against host-system provided cuda libraries (and the libc those libraries are dependent on), for a Jetson ARM-based system. So I'm trying to create overrides for these basic libraries based on tar'ed system libraries. Has anyone tried to use Nix this way?

Yes! Although not for CUDA. I used opencl. nixgl helped here: https://github.com/guibou/nixGL. CUDA should be even simpler since you just add the CUDA .so paths to the RPATH. Allthough I might be missing something. Custom libc might be a whole can of worms though if it happens to be incompatible.

Re: Nix Team Creation

#57

Post by pxc »

callahad wrote: post #20
outworlder wrote: post #15

Earlier quoted context omitted.

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

> Nix is compelling enough today that it could experience explosive growth even if core development was completely stuck. [...] I [do not] know whether this is the case

It felt like that to me for a really long time, in between the releases of Nix 2.3 and 2.4, when there were lots of features being added but there was no release schedule. The divide between flakes users and non-flakes users was also larger then, as the feature was gated behind not just an experimental flag, but pre-release versions of Nix.

Since then, Nix has gotten into a regular, fairly rapid release cycle and new functionality is released pretty often. There are various concerns about what that change does and doesn't fix for Nix, but for me at least there's no longer that feeling of stagnation or mystery about when Nix will see a stable update released.

> 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

Flakes have been conceived and pushed forward by the original author and chief maintainer of Nix. In the earliest stages of their development, consensus proved difficult to build and the community RFC process was very young. Suspending that RFC and adding the features to the master branch but marking them 'experimental' was an attempted compromise on the part of Eelco Dolstra, who had previously more or less taken a BDFL approach to maintaining Nix.

Since then, the flakes implementation has matured quite a bit. I think most users expect that it will evolve into an official feature soon and without many fundamental changes, although some community members still feel some bitterness about that initial process as well as skepticism about the scope and necessity of the whole suite of features that come with flakes.

At the same time, many RFCs have gone through the process since then. The organization of the projects and processes for getting ambitious changes approved are much more explicit now. In those ways, it's clear that leadership/governance in the Nix community is becoming more organized and more effective.

Re: Nix Team Creation

#58

Post by colinsane »

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.

sure, there’s risk in any direction.

> Which means my workplace is stuck with a bunch of `shell.nix` and `direnv` magic instead of clean flake-based envs.

if flakes win out, this other stuff might well be deprecated someday. timeline for that is probably lengthier than the timeline where flakes don’t win, but it’s still there. in either scenario you’re gonna have a month or more between one approach being deprecated and being dropped altogether (6 months if you’re on the stable channel). you’re implicitly betting for or against the success of flakes here, weighted by the cost of refactoring should you bet on the “losing” side plus maintenance until the winner emerges. you describe non-flake maintenance as being higher cost, so from the outside it just feels like a suspicious bet to make.

Re: Nix Team Creation

#59

Post by jalino23 »

tomberek wrote: post #55
outworlder wrote: post #6

Earlier quoted context omitted.

Nix vs NixOS?

Nix is the package manager that works on a multitude of operating systems. Then there was the thought “what if we use this same underlying technology to make a Linux distribution” and “we can manage services in a declarative manner” which became NixOS.

this cleared up the confusion for me thank you

Re: Nix Team Creation

#60

Post by rgoulter »

Arcuru wrote: post #40
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…

The Nix team doesn't allow any community proposals for making changes to Flakes because it is still 'experimental' and hasn't yet gone through an RFC. So it's 'experimental' in the sense that it might change, but the people who have suggested changes to the design are generally told that they won't discuss changes because it's not yet stabilized. That kind of circular reasoning seems problematic. Don't get me wrong,…

> The Nix team doesn't allow any community proposals for making changes to Flakes because it is still 'experimental' and hasn't yet gone through an RFC.

You sound like you have something particular in mind.

If I look at the Nix RFCs, flakes was as RFC 0049 https://github.com/NixOS/rfcs/pull/49

Maybe Alyssa's comment here? https://github.com/NixOS/rfcs/pull/136#discussion_r987278726

Post reply on HN