3 ms·

Because Flakes are simultaneously discouraged and labeled as unfinished, yet used by many. Some aspects of Flakes are a bit contentious. For example, official

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

by nextos 3y ago

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 )