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

NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

github.com

Post reply on HN
Print view View original

121–130 of 186 posts

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#121

Post by pharmakom »

nextos wrote: post #22
bongobingo1 wrote: post #8

Ive always loved the idea of nix, but feel like I've read numerous, if not horror, at least uncomfortable stories about the actual real-world experience after the initial "setup yak shaving" is done - which is often exciting for "us", it's the new project problem solving part before it falls into the boring "work" part. If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux syst…

It can get you two major things. Docker-like reproducibility for any development project in a much more convenient way. And the ability to try lots of software without installing it. For me, the last one is a gamechanger, as I am no longer worried about littering my system with tons of dependencies. Say I want to convert an eBook I downloaded. I can quickly use Calibre for a one-off thing, with nix run nixpkgs#calibr…

This is already solved by Docker. I know Docker has a bunch of issues and Nix is clearly a more elegant design, but in practice Docker works fine (at least for my use case).

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#122

Post by ertian »

bpye wrote: post #80
qbasic_forever wrote: post #14

Earlier quoted context omitted.

It's fine, just be sure you know where your tools are coming from (use the which command a lot when unsure). Nix might have more up to date or bleeding edge software, although since you're on arch in my experience nix can lag even arch by a little bit. Fully reproducible environments with home manager and nixos are neat but IMHO you can just use ansible to do the same thing on debian, arch, etc. if those systems have…

> It's fine, just be sure you know where your tools are coming from (use the which command a lot when unsure). Nix might have more up to date or bleeding edge software, although since you're on arch in my experience nix can lag even arch by a little bit. That'll depend if you're on stable or not. If you're on stable and you need something from unstable that's also possible without any real risk of breakage on NixOS.

Also, once you've learned the ins and outs of Nix (which TBH I didn't find as hard as others, there's tons of examples) it's usually pretty simple to update software yourself--relatively risk-free. For example, I've been keeping Minecraft on the cutting edge for my kid by occasionally updating a URL and hash. A lot of the modules provide a 'package' option to make that easier.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#123

Post by setheron »

biggestlou wrote: post #56
setheron wrote: post #50

Earlier quoted context omitted.

You can still `nix run` packages using niv -- no clue what you talking about. You can also just look at the niv sources.json file pretty easily if you knew the URL. Rather trivial command to run. I don't find the above compelling (or correct?)

nix run github:DeterminateSystems/flake-checker What's the Niv equivalent of this?

# non-flake $ nix run -f https://github.com/fzakaria/mvn2nix/archive/master.tar.gz --command mvn2nix

# flake $ nix run github:fzakaria/mvn2nix#mvn2nix

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#124

Post by rgoulter »

resonious wrote: post #116

Just today I was setting up a server for a side project and mulling over do I use ol' reliable Ubuntu+Ansible vs finally trying NixOS. I was very sad to see that all of the popular VPS services (Digital Ocean and the like) "no longer" officially support NixOS. Linode was nice enough to have an official "how to set up NixOS on Linode" guide, but it requires fiddling with partitions by hand. At that point, I feel like…

Those Linode instructions are about installing an OS from an installation ISO from Linode's rescue mode. -- I'd consider that more a 'plus' to Linode that you get to be able to install whatever unsupported Linux on Linode's VMs. But, of course it's not as smooth as the officially supported images.

Sibling comment mentions that nix has ways to build NixOS VM images (e.g. https://github.com/nix-community/nixos-generators has a generator specifically for Linode).

Another option is to use nixos-infect, which will replace a Linux distribution with a NixOS distribution. https://github.com/elitak/nixos-infect -- e.g. this blogpost discusses using nixos-infect to deploy NixOS for a cloud provider which doesn't have an official NixOS image. https://xeiaso.net/blog/nix-flakes-terraform

> At that point, I feel like all of the repeatability gains are gone. If I want to spin up a fresh server, I have to read a guide and set stuff up by hand?

Just as with ansible, "git pull to deploy". You'd keep a copy of your NixOS configuration.nix somewhere else, and would be able to apply it later.

> it really does let me just get a new VPS and deploy to it very fast

Using a tool you're familiar with to get the job done is going to be faster than learning to use a tool you're unfamiliar with.

I believe much of the use of NixOS is for hobby stuff, and for personal machines. (c.f. "In what environments do you use Nix", Development (1242) vs Home Server (845) vs Production (386) https://discourse.nixos.org/t/2022-nix-survey-results/18983).

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#125

Post by smoldesu »

hlandau wrote: post #105

To date I've paid no attention to Flakes because whenever I look at them, they appear to require me to manually list all target architectures in the Flakes file, which is ridiculous. I'm not going to make the code I publish needlessly dependent on specific architectures. This problem seems to be solved commonly in two ways: - People thoughtlessly and senselessly listing only x86; - People using the popular flake util…

I haven't personally found this to be an issue. I usually define the arches I intend to hit at the beginning of the flake, then pass that list to pkgs so it can track down the independent dependencies:

  allSystems = [
              "x86_64-linux" 
              "aarch64-linux"
              "x86_64-darwin" 
              "aarch64-darwin" 
            ];
  
  forAllSystems = f: nixpkgs.lib.genAttrs allSystems (system: f {
              pkgs = import nixpkgs { inherit system; };
            });
See? Easy as getting a tooth pulled!

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#126

Post by biggestlou »

setheron wrote: post #123
biggestlou wrote: post #56

Earlier quoted context omitted.

nix run github:DeterminateSystems/flake-checker What's the Niv equivalent of this?

# non-flake $ nix run -f https://github.com/fzakaria/mvn2nix/archive/master.tar.gz --command mvn2nix # flake $ nix run github:fzakaria/mvn2nix#mvn2nix

mvn2nix is a flake, though. How would I run a project that uses Niv and isn't a flake?

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#127

Post by [deleted] »

nextos wrote: post #22
bongobingo1 wrote: post #8

Ive always loved the idea of nix, but feel like I've read numerous, if not horror, at least uncomfortable stories about the actual real-world experience after the initial "setup yak shaving" is done - which is often exciting for "us", it's the new project problem solving part before it falls into the boring "work" part. If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux syst…

It can get you two major things. Docker-like reproducibility for any development project in a much more convenient way. And the ability to try lots of software without installing it. For me, the last one is a gamechanger, as I am no longer worried about littering my system with tons of dependencies. Say I want to convert an eBook I downloaded. I can quickly use Calibre for a one-off thing, with nix run nixpkgs#calibr…

[deleted]

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#128

Post by setheron »

biggestlou wrote: post #126
setheron wrote: post #123

Earlier quoted context omitted.

# non-flake $ nix run -f https://github.com/fzakaria/mvn2nix/archive/master.tar.gz --command mvn2nix # flake $ nix run github:fzakaria/mvn2nix#mvn2nix

mvn2nix is a flake, though. How would I run a project that uses Niv and isn't a flake?

I actually support both by having default.nix

At this point I recommend we take this through another medium like email or feel free to open up a discourse to help fill in the knowledge gap. Feel free to tag me on it.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#129

Post by ParetoOptimal »

bergkvist wrote: post #23

The biggest show-stoppers for me with flakes is: Building third party flakes takes forever since every flake uses its own version of nixpkgs. If you don't pin your third party flake urls they might also change under your nose as you run the same command again a day later. Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding. I've wasted more time tha…

> Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding.

You only need to `git add` the file once.

You do not need to stage every change after that before flakes can "see" the change.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#130

Post by chriswarbo »

Cloudef wrote: post #63
sourcegrift wrote: post #53

My biggest problem with flakes is that it is too much added complexity for tiny incremental gains (as per my limited understanding, happy to be corrected). Not only do most users gain very, very little from it, it also deters users from using nix for two reasons: 1) There is more to learn now. 2) Split ecosystem. I'm looking to be educated, I've made contributions to nixpkgs (two "mid-sized" changes) but for some rea…

You can do everything without flakes as well by using fetchTarball, fetchGit etc, with shasums, but flakes just improves the ergonomics. Because of the lock files, flakes are also faster, especially nice if you use nix develop (the new nix-shell alt)

> Because of the lock files, flakes are also faster

I consider lock files to be labour-intensive work-arounds for fundamental design problems. One of the things I like about Nix is that its design doesn't need them, and even allows me to automate-away their need in other tools (e.g. defining a project's "main" derivations using import-from-derivation on the result of a lock-file-generating derivation; this works well with legacy tools like Maven, for example)

Post reply on HN