Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nix and NixOS, my pain points

remy.grunblatt.org

Post reply on HN
Print view View original

21–30 of 109 posts

Re: Nix and NixOS, my pain points

#21

Post by pshirshov »

viraptor wrote: post #19
pshirshov wrote: post #15

The real pain points are: 1) Abysmal contributor experience 2) Lack of typing in nix language and very limited debugging capabilities 3) Lack of interface concept in nix language 4) Lack of any markings on dependency graph edge 5) (3) and (4) makes impossible to have anything alike to gentoo's slots. Nix might be the only right way of doing slotting but it's effectively incapable of that.

What do you mean in pt 1? I've not experienced any issues there, but curious to hear from others.

Normal flow in other distros I contributed to: "thanks for the patch, we'll do the rest".

Nix flow: your patch is not done according to our guidelines, so fuck off. Still not. Still not. Read the guidelines. Still not, read the guidelines. You have to squash commits manually, we won't enable autosquashing because someone important doesn't like them. Nope, your time isn't valuable because there are too many of you and just one nix.

It's like they enjoy spending time to tell occasional contributors, who can't memorize all nix rituals, "fuck off" instead of spending that time to do the necessary finishing touches.

So, critical issues/vulnerabilities remain unpatched, some formulas are outdated by 5 years, because the relevant maintainer says the old package works for him but new one breaks something on his machine and offers to investigate his issue on your own by a single log line. Of course completely ignoring all _your_ issues which are fixed in an upstream patch made one year ago.

I know people who decided not to make a single contribution to nixpkgs until the things change because of that shitshow and I joined that movement. It's really easier to have a personal private fork of nixpkgs and make all the changes there instead of dealing with the upstream and that's what I would strongly recommend to any nix newcomer.

Re: Nix and NixOS, my pain points

#22

Post by scoopertrooper »

laserlight wrote: post #16
40yearoldman wrote: post #3

Earlier quoted context omitted.

I keep reading, this, and keeping being told this. Yet I switched every system over to nix and have found no thing but the best examples documentation and help from nix to do so. Within the span of a afternoon and a bit a reading I went from zero, to a script that lets me setup an entire dev systems with just a few commands in a vm, and or even on hardware. If anything the Nix documentation is just as good as every o…

By documentation, I believe people mean tutorials. At least, lack of tutorials is my complaint. I've read all introductory material. I want to build a customized version of emacs on nix, yet I have no idea how to do it or where to start.

Why use a tutorial when ChatGPT has you covered?

> How do I create a nix package that clones eMacs from GitHub and builds it from source?

{ pkgs ? import {}, fetchFromGitHub }:

let

  emacsSrc = fetchFromGitHub {

    owner = "emacs-mirror";

    repo = "emacs";

    rev = "master";

    sha256 = "0xabcd1234";

  };
in pkgs.stdenv.mkDerivation {

  name = "emacs";

  version = "27.1";

  src = emacsSrc;

  buildInputs = [ pkgs.autoconf pkgs.make ];

  configurePhase = ''

    autoconf

    ./configure --prefix=$out

  '';

  buildPhase = "make";

  installPhase = "make install";

}

Re: Nix and NixOS, my pain points

#23

Post by johnvaluk »

viraptor wrote: post #6

> When we use NixOS, and we want to use a package that is not available under NixOS / Nixpkgs (which happens quite often), we have only one choice: pack it into NixOS. That's not the only way. It's definitely the easiest option, but you can also create a temporary fhs environment https://github.com/ElvishJerricco/nixpkgs/commit/05742c15d5a...

See the NixOS manual for more information on buildFHSUserEnv (https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment...).

Re: Nix and NixOS, my pain points

#24

Post by sierkov »

Reventlov wrote: post #10
sierkov wrote: post #9

Earlier quoted context omitted.

> for example allowing to specify environment variables in manifest.scm files. There is already .envrc or .dir-locals.el? And manifest is just - well - manifest. By definition it has to be 'plain'. I mean, there are already a million ways to load env vars so why'd you want guix to do that too and from manifest.scm of all places?

Because instead of distributing two files (channels.scm and manifest.scm, or flake.lock and flake.nix), you have to execute monstruosities like `guix shell --container -m ./manifest.scm -- bash -c 'GUIX_LOCPATH=$GUIX_ENVIRONMENT/lib/locale LC_ALL=fr_FR.utf-8 exec jekyll build'`, which is how I build some websites I have. To me, that's not ok from an user experience point of view.

Exactly my point. You can already do it with direnv, have guix shell once you cd into dir and then just do `jekyll build`.

Re: Nix and NixOS, my pain points

#25

Post by delroth »

scoopertrooper wrote: post #22
laserlight wrote: post #16

Earlier quoted context omitted.

By documentation, I believe people mean tutorials. At least, lack of tutorials is my complaint. I've read all introductory material. I want to build a customized version of emacs on nix, yet I have no idea how to do it or where to start.

Why use a tutorial when ChatGPT has you covered? > How do I create a nix package that clones eMacs from GitHub and builds it from source? { pkgs ? import {}, fetchFromGitHub }: let emacsSrc = fetchFromGitHub { owner = "emacs-mirror"; repo = "emacs"; rev = "master"; sha256 = "0xabcd1234"; }; in pkgs.stdenv.mkDerivation { name = "emacs"; version = "27.1"; src = emacsSrc; buildInputs = [ pkgs.autoconf pkgs.make ]; confi…

As usual for ChatGPT this is full of mistakes and bad code. The buildPhase and installPhase it writes are completely unnecessary and worse than the default, the configurePhase might work in some cases but most likely won't, and it's unnecessary when instead autoreconfHook should be used, stdenv/autoconf should be taken as an argument for the function returning the derivation, autoconf should be a nativeBuildInput, make is already in stdenv, etc.

Re: Nix and NixOS, my pain points

#26

Post by rgoulter »

Regarding the second point, ("it's not enough to have the same /etc/nixos/configuration.nix file, because of environment variables, other files, and commit revisions of repos used"), this is one thing which Nix Flakes solves.

With nix flakes, all the Nix sources you use must be checked into source control, and impurities like environment variables can't be used (by default).

Re: Nix and NixOS, my pain points

#27

Post by Reventlov »

rgoulter wrote: post #26

Regarding the second point, ("it's not enough to have the same /etc/nixos/configuration.nix file, because of environment variables, other files, and commit revisions of repos used"), this is one thing which Nix Flakes solves. With nix flakes, all the Nix sources you use must be checked into source control, and impurities like environment variables can't be used (by default).

This is actually the opposite, by default, impurities like environment variables can still be used, as well as binaries, or other things !

A small example :

```

[remy@typhoon:~/Blog]$ cat flake.nix { inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixos-22.11"; };

  outputs = { self, nixpkgs }:
    let pkgs = nixpkgs.legacyPackages.x86_64-linux;
    in
    {
      devShell.x86_64-linux =
        with pkgs;
        pkgs.mkShell {
          buildInputs = [
            python3Packages.pelican
            python3Packages.markdown
          ];
        };
    };
}

[remy@typhoon:~/Blog]$ export HELLO="WORLD"

[remy@typhoon:~/Blog]$ nix develop

warning: Git tree '/home/remy/Blog' is dirty

[remy@typhoon:~/Blog]$ echo $HELLO

WORLD

```

And, because flakes are not stable, you need to enable them with e.g. `--experimental-features 'nix-command flakes'`. And by default, you can still access outside binaries, like let's say ls ! Which is why, to have real hermetic builds, in Guix for example, it's advised to run in containers and so on.

Re: Nix and NixOS, my pain points

#28

Post by lom »

pshirshov wrote: post #21
viraptor wrote: post #19

Earlier quoted context omitted.

What do you mean in pt 1? I've not experienced any issues there, but curious to hear from others.

Normal flow in other distros I contributed to: "thanks for the patch, we'll do the rest". Nix flow: your patch is not done according to our guidelines, so fuck off. Still not. Still not. Read the guidelines. Still not, read the guidelines. You have to squash commits manually, we won't enable autosquashing because someone important doesn't like them. Nope, your time isn't valuable because there are too many of you and…

This couldn’t be any further from my experience. Instead of being told fuck off, I was offered (and later offered when I became a maintainer myself) constructive criticism, often times with the patches, required to make it up to standard, included.

> maintainer says the old package works for him

We’re all just volunteers, who are doing this in our free time. Usually this works well enough for most packages, but you are always free to submit the fix yourself on nixpkgs ;). At least compared to other distros, that workflow simpler.

Re: Nix and NixOS, my pain points

#29

Post by rgoulter »

pshirshov wrote: post #21
viraptor wrote: post #19

Earlier quoted context omitted.

What do you mean in pt 1? I've not experienced any issues there, but curious to hear from others.

Normal flow in other distros I contributed to: "thanks for the patch, we'll do the rest". Nix flow: your patch is not done according to our guidelines, so fuck off. Still not. Still not. Read the guidelines. Still not, read the guidelines. You have to squash commits manually, we won't enable autosquashing because someone important doesn't like them. Nope, your time isn't valuable because there are too many of you and…

> Nope, your time isn't valuable because there are too many of you and just one nix.

This ... seems entirely reasonable, though?

As you point out, having to do extra work on behalf of others isn't desirable.

-- If a pull request is made and the maintainer(s) don't like it, the options are "reject it", "maintainer puts in extra work to accept it", "pull request author puts in extra work to get it accepted".

With as many open PRs to nixpkgs as there are, it seems reasonable to ask that pull requests are as streamlined as possible.

That this isn't a great experience for new (or infrequent) contributors is unfortunate; although, "contributing" was raised as a pain point in the last community survey. https://discourse.nixos.org/t/2022-nix-survey-results/18983

Re: Nix and NixOS, my pain points

#30

Post by Foxboron »

Slight misunderstanding in the blog post there.

> Archlinux is 78% reproducible on amd64 packages

> Debian is 95.7% reproducible on amd64 packages

This references the "fuzzing" infrastructure hosted by the Reproducible Builds project, and doesn't show "true" reproduction of binaries. It's designed to help us figure out where impurites occur in builds.

Proper package reproduction is much better in Arch because we don't have to care about all differences that can occur since our build systems are mostly static.

The true number hover around 86%-90%, which is better than the CI system.

https://reproducible.archlinux.org/

The main issues here is regressions in compilers, build tooling and leaky abstractions that needs to be found and patched. An example is how i spent a month tracking down a gcc bug that caused cgo builds to be unreproducible.

https://go-review.googlesource.com/c/go/+/413974

Post reply on HN