Live data from Hacker News

Nix Team Creation

discourse.nixos.org

41–50 of 65 posts

Re: Nix Team Creation

#41

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…

> 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?

Re: Nix Team Creation

#42
I think this is a great move, but like every FOSS project I am interested what the finding situation will look like, both short and long term.

(One guesses they have software dev jobs and will have some % of time dedicated to that).

Re: Nix Team Creation

#43
post #31

Earlier quoted context omitted.

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.

Should work for portable apps, or anything else that's distributed as an archive that can be directly extracted and work (So AIUI a tiny fraction of the available software. Still, it's not nothing.)

You could probably wrap Scoop packages into a Wine environment with Nix fairly easily, since all the packages in their main repos are well-behaved, portable, and install non-interactively.

Re: Nix Team Creation

#44
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…

The new Nix command syntax that was there up to 2.3 was always marked as experimental, but it worked fine for many years, I used it in many projects ... until it got deleted and replaced with flakes. I really hope they don't do that again. Flakes are de facto adopted by now, if they break it once more, it will fragment the ecosystem. Though there are rough edges where a breaking change would be beneficial in the long run.

Re: Nix Team Creation

#45
post #8

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…

These questions highlight the overwhelm that users can feel as they're getting started with Nix. The Nix ecosystem is so replete with divergent possibilities that navigating it can absolutely play into paralysis by analysis, and lead users to hesitate to learn more because they don't know where to start or which competing tools in the ecosystem are more suitable or more likely to be 'the future'. That is an experience of floundering for sure.

But in terms of contributions, capabilities, and userbase, the Nix lately been subject to impressive and exciting growth that you mention. I think the best is yet to come, but it's already fair to say that Nix is flourishing.

The community and the codebases also do have growing pains, of course. But I don't think that Nix is floundering at all.

Re: Nix Team Creation

#46

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 significantly easier to create an standalone package or module for your specific needs since you import it just like nixpkgs. It also means that software doesn't have to be part of nixpkgs to be usable on the system - if a git repo has a flake it's just a matter of adding it as an input. Flakes represent such a massive improvement to the way that you interact with nix, I sincerely hope they become the default here soon. In the meantime, it is well worth your effort to learn them even if they aren't 'required' yet.

Unfortunately all of this is contingent on being able to grok the language in the first place which is where the documentation really falters. The nix pills talk about the basics of the language but it is very difficult to make anything useful without importing some libraries (i.e. nixpkgs) - and these libraries are not very well documented. I am aware of a documentation team being formed to help address this but it still remains the number one issue with nix, especially for newcomers. The unfortunate thing is that there are so many moving parts that it will take a considerable effort to explain the entire ecosystem without being overwhelming but still providing enough intuition for newcomers to get things done with Nix.

If anyone is interested, a recent SoN talk was given about efforts to improve the documentation. It touches on many of the things I bought up here: https://www.youtube.com/watch?v=WFRQvkfPoDI

Re: Nix Team Creation

#47

Earlier quoted context omitted.

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

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

Re: Nix Team Creation

#48
post #25
post #5

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

Nix is the package manager. nixpkgs is the ecosystem, since it contains all the packages.

Nixpkgs is certainly the core of the ecosystem, but it's not at all the whole ecosystem.

Other important parts of the NixOS ecosystem include:

  - NixOS, the main module system which adds many configuration management capabilities to Nix
  - Nix-Darwin and home-manager, extremely popular module systems for using Nix for configuration management on other operating systems
  - various deployment tools: NixOps, Hail, Colmena, deploy-rs, Terranix
  - pre-flake version pinning tools like Niv
  - flake libraries like flake-utils, flake-utils-plus, std, and flake-parts
  - development environment utilities and libraries like devshell, Lorri, and integrations like those of direnv and shadowenv
  - the Nix User Repository and various important overlays (e.g., the Emacs overlay, the Rust overlays)
  - the many 2nix conversion tools, some of which are chiefly distributed outside of Nixpkgs and used to package things in private or company collections rather than in Nixpkgs
  - arguably some proprietary commercial products and SaaS offerings, like Cachix, Hercules CI, and Flox
  - the NixOS hardware profiles collection
  - the Nix and NixOS manuals
  - important unofficial documentation sources, like nix.dev and nixos.wiki, and even important blog series like the Nix Pills or Ian Henry's reading of the official documentation
  - wrappers and developer applications based on Nix, like devboxes and nixpacks
  - GUI tools for working with Nix code or configuring NixOS, graphical app stores, etc.
  - editor integrations like rnix-lsp, nix-mode, and environment management plugins for various editors
  - a couple of really cool tools for automatically creating portable/deployable shell scripts with Nix (binlore + resholve)
  - tools for generating magic fat binaries based on container technologies, like nix-bundle
  - partial reimplementations of various parts of the Nix stack for specialized use in other programs, or sometimes aspiring to compete with Nix (like tvix)
Some of that stuff is included in Nixpkgs, but that's almost incidental— the ecosystem is not just the packages qua packages, but also various specialized tools and community knowledge which has been accumulated in the form of configuration modules and documentation. Those projects are first-class members of the Nix ecosystem in their own right, not only as things that might be included as packages in Nixpkgs :)

(And of course leveraging Nix successfully doesn't mean one has to evaluate or learn all of these tools. Most users will organically discover and stick with just a handful of them according to the demands of their own use cases. But in total, there is a really wide landscape of Nix-based and Nix-related software out there.)

Re: Nix Team Creation

#49

Earlier quoted context omitted.

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

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.

Re: Nix Team Creation

#50
post #31
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.

For what it's worth most of the "packages" on chocolatey are just instructions for downloading those same installers and executing them in their respective silent modes. No one is repackaging those apps except for maybe some of the ones marked as "portable".
Post reply on HN