7 ms·

> With the goal of ending this current limbo and soothe longstanding tensions in the Nix community Can someone with more background give a quick explanation ab

by m1keil 3y ago

> With the goal of ending this current limbo and soothe longstanding tensions in the Nix community Can someone with more background give a quick explanation about why is this a source of tension in the nix community in the first place? Is this a situation of too many cooks in the kitchen or something else?

nextos 3y ago
Because Flakes are simultaneously discouraged and labeled as unfinished, yet used by many. Some aspects of Flakes are a bit contentious. For example, official adoption of Flakes will mean Nix will no longer be a mono-repository. Plus, Flakes are tightly coupled to Git. However, Flakes bring welcome improvements to longstanding issues. Most notably, package pinning and explicit versioning, which are problematic when using channels.
- PuercoPop 3y ago
  I use nix with flakes, have written a couple of flakes day to day use. I am not a nix power user. But based on my current understanding this statement seems incorrect > Flakes are tightly coupled to Git. How is it tightly coupled to Git if it supports Mercurial out of the box? Other than using version control to determine what are the sources of the derivation, what does flakes lean on version control?
  - nextos 3y ago
    I meant this kind of issue: https://discourse.nixos.org/t/can-i-use-flakes-within-a-git-repo-without-committing-flake-nix/18196 https://discourse.nixos.org/t/can-i-use-flakes-within-a-git-...
    - PuercoPop 3y ago
      That is what I was trying to say by > Other than using version control to determine what are the sources of the derivation I don't think that defaulting to using git to list the sources when inside a git repo means that it is tightly coupled to git. If one doesn't want to commit/stage the flake files in the repo one can do `nix develop .` and it works . It will take a little longer because it will copy the entire directory to the store iiuc.
- hamandcheese 3y ago
  > For example, official adoption of Flakes will mean Nix will no longer be a mono-repo. Do you mean nixpkgs? I don't think stabilizing flakes means nixpkgs won't remain a monorepo.
- chriswarbo 3y ago
  > However, Flakes bring welcome improvements to longstanding issues. Most notably, package pinning and explicit versioning, which are problematic when using channels. I'm still not convinced by flakes; however, I agree that channels are problematic (and I still don't fully understand them, after a decade!). The first things I do after installing Nix are to delete all the channels and unset `NIX_PATH`. I used to use `<nixpkgs>` for bootstrapping via `fetchgit`, but even that's unnecessary now that `fetchGit` is part of `builtins` :)
  - bergkvist 3y ago
    `fetchTarball` with a github archive link is much faster than `fetchGit` for bootstrapping nixpkgs.
    - chriswarbo 3y ago
      Yes, to get Nixpkgs it's much faster to use `fetchTarball`. You're right that `builtins.fetchTarball` is faster than `builtins.fetchGit` (due to the ridiculous amount of commits in the Nixpkgs repo). I like to keep such definitions in a single, company-wide/project-agnostic git repo (what the Nix Pills series calls the "repository pattern"), and have individual projects import them via `builtins.fetchGit`. Many years ago we didn't have `builtins.fetchGit`, so had to use the 'fetchgit' function from Nixpkgs instead. That created a chicken-and-egg situation if we wanted to take the Nixpkgs version from some other git repo; hence needing to "bootstrap" via `(import <nixpkgs> { config = {}; }).fetchgit`, and cross our fingers that `NIX_PATH` wasn't set to some crazy value (which, of course, I would inevitably do... https://github.com/Warbo/haskell-te/blob/24475a229908caa344788a0907a67e67cd62dbdd/nix-support/withNix.nix#L12 https://github.com/Warbo/haskell-te/blob/24475a229908caa3447... ) Note that we need `config = {};` when importing Nixpkgs to avoid an impurity which tries to read files in $HOME. More recent versions of Nixpkgs also need `overlays = [];` to avoid another impurity (looks like this changed at Nixpkgs 17.03, according to https://github.com/Warbo/nix-helpers/blob/master/nixpkgs.nix https://github.com/Warbo/nix-helpers/blob/master/nixpkgs.nix )
RaitoBezarius 3y ago
For example, Flakes have no concept of cross compilation and makes this use case extremely tedious to use. Flakes were a RFC then merged as an experimental feature and shilled too much to the community to the point they are now a quasi standardized feature even though they didn't go through RFC and therefore ignored all the valuable feedback. This whole debacle made a lot of invested people tired on both sides.
- predictabl3 3y ago
  > Flakes have no concept of cross compilation and makes this use case extremely tedious to use. I don't agree at all. I use flakes with cross compilation literally all of the time. Having a concept of "cross-compilation" at the CLI level, instead of being part of the nix evaluation itself would be a travesty IMO. I love being able to do a single nix eval that includes 3 different architecture of native builds for my host toplevels, along with "cross" variants that set hostPlatform to x86 and produce cross-builds.
- 40yearoldman 3y ago
  What? I compile my arm64 system on a amd64 system and send them to my cache server so my arm systems don’t have to do the work and just download the outputs and apply them.
  - seabass-labrax 3y ago
    That's something I would like to try for my PinePhone. It's been tedious to do development for it, as the PinePhone's CPU struggles with most compilation tasks. Using Nix would be a good way of building for that platform's somewhat exotic features (arm64 and musl libc) on a more powerful machine, without confusing the system package manager with package versions outside the distribution - I should be able to copy the Nix derivations over and install them temporarily with nix-shell. Thanks for the inspiration!
    - 40yearoldman 3y ago
      Make sure you use copy-closure and target the result directory. My fist attempts had some crazy find script copying all of nix-store with copy-closure. You can skip this part if you make the build machine the same as the cache machine as the results are automatically cached.
tkz1312 3y ago
I think most of the issues are more social than technical. A lot of people feel that flakes were pushed through to serve the needs of their corporate sponsor (target) without adequate time spent responding to community feedback. There is (was?) also some opposition to the way that they were designed to break up the nixpkgs monorepo.

by m1keil 3y ago

nextos 3y ago

Because Flakes are simultaneously discouraged and labeled as unfinished, yet used by many. Some aspects of Flakes are a bit contentious. For example, official adoption of Flakes will mean Nix will no longer be a mono-repository. Plus, Flakes are tightly coupled to Git. However, Flakes bring welcome improvements to longstanding issues. Most notably, package pinning and explicit versioning, which are problematic when using channels.

PuercoPop 3y ago
I use nix with flakes, have written a couple of flakes day to day use. I am not a nix power user. But based on my current understanding this statement seems incorrect > Flakes are tightly coupled to Git. How is it tightly coupled to Git if it supports Mercurial out of the box? Other than using version control to determine what are the sources of the derivation, what does flakes lean on version control?
- nextos 3y ago
  I meant this kind of issue: https://discourse.nixos.org/t/can-i-use-flakes-within-a-git-repo-without-committing-flake-nix/18196 https://discourse.nixos.org/t/can-i-use-flakes-within-a-git-...
  - PuercoPop 3y ago
    That is what I was trying to say by > Other than using version control to determine what are the sources of the derivation I don't think that defaulting to using git to list the sources when inside a git repo means that it is tightly coupled to git. If one doesn't want to commit/stage the flake files in the repo one can do `nix develop .` and it works . It will take a little longer because it will copy the entire directory to the store iiuc.
hamandcheese 3y ago
> For example, official adoption of Flakes will mean Nix will no longer be a mono-repo. Do you mean nixpkgs? I don't think stabilizing flakes means nixpkgs won't remain a monorepo.
chriswarbo 3y ago
> However, Flakes bring welcome improvements to longstanding issues. Most notably, package pinning and explicit versioning, which are problematic when using channels. I'm still not convinced by flakes; however, I agree that channels are problematic (and I still don't fully understand them, after a decade!). The first things I do after installing Nix are to delete all the channels and unset `NIX_PATH`. I used to use `<nixpkgs>` for bootstrapping via `fetchgit`, but even that's unnecessary now that `fetchGit` is part of `builtins` :)
- bergkvist 3y ago
  `fetchTarball` with a github archive link is much faster than `fetchGit` for bootstrapping nixpkgs.
  - chriswarbo 3y ago
    Yes, to get Nixpkgs it's much faster to use `fetchTarball`. You're right that `builtins.fetchTarball` is faster than `builtins.fetchGit` (due to the ridiculous amount of commits in the Nixpkgs repo). I like to keep such definitions in a single, company-wide/project-agnostic git repo (what the Nix Pills series calls the "repository pattern"), and have individual projects import them via `builtins.fetchGit`. Many years ago we didn't have `builtins.fetchGit`, so had to use the 'fetchgit' function from Nixpkgs instead. That created a chicken-and-egg situation if we wanted to take the Nixpkgs version from some other git repo; hence needing to "bootstrap" via `(import <nixpkgs> { config = {}; }).fetchgit`, and cross our fingers that `NIX_PATH` wasn't set to some crazy value (which, of course, I would inevitably do... https://github.com/Warbo/haskell-te/blob/24475a229908caa344788a0907a67e67cd62dbdd/nix-support/withNix.nix#L12 https://github.com/Warbo/haskell-te/blob/24475a229908caa3447... ) Note that we need `config = {};` when importing Nixpkgs to avoid an impurity which tries to read files in $HOME. More recent versions of Nixpkgs also need `overlays = [];` to avoid another impurity (looks like this changed at Nixpkgs 17.03, according to https://github.com/Warbo/nix-helpers/blob/master/nixpkgs.nix https://github.com/Warbo/nix-helpers/blob/master/nixpkgs.nix )

RaitoBezarius 3y ago

For example, Flakes have no concept of cross compilation and makes this use case extremely tedious to use. Flakes were a RFC then merged as an experimental feature and shilled too much to the community to the point they are now a quasi standardized feature even though they didn't go through RFC and therefore ignored all the valuable feedback. This whole debacle made a lot of invested people tired on both sides.

predictabl3 3y ago
> Flakes have no concept of cross compilation and makes this use case extremely tedious to use. I don't agree at all. I use flakes with cross compilation literally all of the time. Having a concept of "cross-compilation" at the CLI level, instead of being part of the nix evaluation itself would be a travesty IMO. I love being able to do a single nix eval that includes 3 different architecture of native builds for my host toplevels, along with "cross" variants that set hostPlatform to x86 and produce cross-builds.
40yearoldman 3y ago
What? I compile my arm64 system on a amd64 system and send them to my cache server so my arm systems don’t have to do the work and just download the outputs and apply them.
- seabass-labrax 3y ago
  That's something I would like to try for my PinePhone. It's been tedious to do development for it, as the PinePhone's CPU struggles with most compilation tasks. Using Nix would be a good way of building for that platform's somewhat exotic features (arm64 and musl libc) on a more powerful machine, without confusing the system package manager with package versions outside the distribution - I should be able to copy the Nix derivations over and install them temporarily with nix-shell. Thanks for the inspiration!
  - 40yearoldman 3y ago
    Make sure you use copy-closure and target the result directory. My fist attempts had some crazy find script copying all of nix-store with copy-closure. You can skip this part if you make the build machine the same as the cache machine as the results are automatically cached.

tkz1312 3y ago

I think most of the issues are more social than technical. A lot of people feel that flakes were pushed through to serve the needs of their corporate sponsor (target) without adequate time spent responding to community feedback. There is (was?) also some opposition to the way that they were designed to break up the nixpkgs monorepo.