6 ms·

Nix Team Creation

155 points by slb 4y ago

thomastjeffery 4y ago
Good news. Nix has really been floundering lately. It needs some assertive direction.
- colordrops 4y ago
  Has it been floundering? Could you provide some context?
  - n42 4y ago
    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 the fate of the Nix language? Should I start investing in this new language? Why is documentation still so bad? Why is there not a clear and official answer to documentation generation? Syntax linting? Testing? Who is in charge of trying to fix SEO for documentation? Nix is technologically sound but is struggling organizationally from its explosive growth
    - rgoulter 4y ago
      > 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'.
      - nvln 4y ago
        > 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.
      - nonbirithm 4y ago
        >> 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.
        parminya 4y ago
        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.
        colordrops 4y ago
        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.
        hakre 4y ago
        Perhaps the script is missing that declares what is undefined behaviour in flakes.
        0x457 4y ago
        Well, it is experimental. Experimental rarely means "It's not going to work and might delete your data" that what, ironically, alpha and beta mean.
    - nvln 4y ago
      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.
      - yjftsjthsd-h 4y ago
        I find "nixos" works well, even when I don't mean the Linux distro. YMMV. (And yes, I absolutely agree that if we could go back in time and change it to pretty much anything else that would be better.)
    - outworlder 4y ago
      > explosive growth That's the opposite of floundering, no?
      - callahad 4y ago
        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.
        pxc 4y ago
        > 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.
    - pxc 4y ago
      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.
  - rgoulter 4y ago
    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.html https://nixos.org/manual/nix/stable/release-notes/rl-2.11.ht...
    - abathur 4y ago
      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.
- sterlind 4y ago
  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.
nonbirithm 4y ago
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 excessively mentioned essay about Lisp hackers keeping to themselves. I wonder if there's something intrinsic to certain developer-oriented projects like these that lead people to tinker with them on their own for long periods of time.
- uncletaco 4y ago
  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.
jalino23 4y ago
>> Nix is the cornerstone of the ecosystem I thought Nix is the ecosystem?
- outworlder 4y ago
  Nix vs NixOS?
  - tomberek 4y ago
    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.
    - jalino23 4y ago
      this cleared up the confusion for me thank you
- Ericson2314 4y ago
  Hopefully some things get renamed eventually!
  - Smaug123 4y ago
    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-meeting-notes-8/21241 https://discourse.nixos.org/t/2022-08-25-documentation-team-...)
    - pxc 4y ago
      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.
nvln 4y ago
Fantastic. This year I managed to get my development environment(s) with declarative, shared configurations almost completely managed by nix. This is the first success for me after trying to do this with multiple tools over the past decade. I'm blown away by what Nix/NixOS has accomplished without having a formal team in place. Kudos to the maintainer(s), community and best wishes to the new Nix Team.
outworlder 4y ago
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.
- parminya 4y ago
  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.
  - aidenn0 4y ago
    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.
amelius 4y ago
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?
- rowanG077 4y ago
  Yes! Although not for CUDA. I used opencl. nixgl helped here: https://github.com/guibou/nixGL 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.
lifeisstillgood 4y ago
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).

Nix Team Creation

155 points by slb 4y ago

thomastjeffery 4y ago

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

colordrops 4y ago
Has it been floundering? Could you provide some context?
- n42 4y ago
  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 the fate of the Nix language? Should I start investing in this new language? Why is documentation still so bad? Why is there not a clear and official answer to documentation generation? Syntax linting? Testing? Who is in charge of trying to fix SEO for documentation? Nix is technologically sound but is struggling organizationally from its explosive growth
  - rgoulter 4y ago
    > 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'.
    - nvln 4y ago
      > 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.
    - nonbirithm 4y ago
      >> 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.
      - parminya 4y ago
        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.
        colordrops 4y ago
        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.
      - hakre 4y ago
        Perhaps the script is missing that declares what is undefined behaviour in flakes.
      - 0x457 4y ago
        Well, it is experimental. Experimental rarely means "It's not going to work and might delete your data" that what, ironically, alpha and beta mean.
  - nvln 4y ago
    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.
    - yjftsjthsd-h 4y ago
      I find "nixos" works well, even when I don't mean the Linux distro. YMMV. (And yes, I absolutely agree that if we could go back in time and change it to pretty much anything else that would be better.)
  - outworlder 4y ago
    > explosive growth That's the opposite of floundering, no?
    - callahad 4y ago
      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.
      - pxc 4y ago
        > 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.
  - pxc 4y ago
    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.
- rgoulter 4y ago
  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.html https://nixos.org/manual/nix/stable/release-notes/rl-2.11.ht...
  - abathur 4y ago
    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.
sterlind 4y ago
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.

nonbirithm 4y ago

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 excessively mentioned essay about Lisp hackers keeping to themselves. I wonder if there's something intrinsic to certain developer-oriented projects like these that lead people to tinker with them on their own for long periods of time.

uncletaco 4y ago
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.

jalino23 4y ago

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

outworlder 4y ago
Nix vs NixOS?
- tomberek 4y ago
  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.
  - jalino23 4y ago
    this cleared up the confusion for me thank you
Ericson2314 4y ago
Hopefully some things get renamed eventually!
- Smaug123 4y ago
  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-meeting-notes-8/21241 https://discourse.nixos.org/t/2022-08-25-documentation-team-...)
  - pxc 4y ago
    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.

nvln 4y ago

Fantastic. This year I managed to get my development environment(s) with declarative, shared configurations almost completely managed by nix. This is the first success for me after trying to do this with multiple tools over the past decade. I'm blown away by what Nix/NixOS has accomplished without having a formal team in place. Kudos to the maintainer(s), community and best wishes to the new Nix Team.

outworlder 4y ago

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.

parminya 4y ago
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.
- aidenn0 4y ago
  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.

amelius 4y ago

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?

rowanG077 4y ago
Yes! Although not for CUDA. I used opencl. nixgl helped here: https://github.com/guibou/nixGL 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.

lifeisstillgood 4y ago

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