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

Nix is the ultimate DevOps toolkit

tech.channable.com

Post reply on HN
Print view View original

201–210 of 243 posts

Re: Nix is the ultimate DevOps toolkit

#201

Post by pwm »

bennyp101 wrote: post #2

As an aside, I've just started trying to move my laptop to NixOS this past week, so far it seems pretty nice. I have a Macbook as well, and I think I should be able to share the Nix stuff with that - which would be cool. As for the article, I hadn't actually considered using it as a replacement for Ansible etc - but I could see why it might work better. I could pin packages etc to the versions, and get the exact same…

Re Macbook, if you fancy check out my home-manager config: https://github.com/pwm/nix-home

The readme was/is more of a short note to myself than for users, nevertheless this is how i manage my entire home env on my mac and it works beautifully.

Re: Nix is the ultimate DevOps toolkit

#202

Post by takeda »

microtonal wrote: post #87
siraben wrote: post #55

Earlier quoted context omitted.

FYI nix-env operations are atomic and can be rolled back instantly, including upgrades. $ nix-env --rollback > The suggestion in the github issue was to instead use an unofficial third party package for basic package management. Specifically the suggestion is referring to home-manager, which is community supported (being in nix-community) and is the recommended way to install packages rather than imperatively doing i…

the recommended way to install packages rather than imperatively doing it with nix-env The problem is: recommended by whom? The Nix Manual presents nix-env as the main way to install Nix packages. So, as long as the manual centers around nix-env , newcomers will try to use nix-env and get bitten by it. The same is true for the NixOS Manual, it suggests that people install packages with nix-env before talking about de…

It's recommended by people who used Nix for a while.

I have a different opinion myself though. While I don't use nix-env anymore I think it is important because serves as a bridge between nix and what people are typically expecting.

I think nix-env syntax should be improved to be similar what you expect with other package managers though.

Once you understand how nix operates you can then stop using nix-env.

I personally use nix for development. For every project I define the whole environment including all tools I need for development. This ensures that if someone needs to work on my project can get the same dev environment. If you add a tool like direnv to the mix it makes the experience much, much better, because then environment is automatically set up as soon as you enter the project directory.

Re: Nix is the ultimate DevOps toolkit

#203

Post by kaba0 »

microtonal wrote: post #140
oblio wrote: post #123

Earlier quoted context omitted.

Today's new users are tomorrow's experienced users. I guess it depends on what Nix wants, if it wants to remain a niche system, then things are good as-is. Though, on the other hand, the comment says a new CLI is close to release, so I guess people are trying to improve things.

Though, on the other hand, the comment says a new CLI is close to release, so I guess people are trying to improve things. I don't want to be too critical, I love Nix. But the experimental new UI was already in development (and available) when I started using Nix in 2018. It has also changed quite a lot recently and is now very strongly tied to flakes. However, the flakes RFC was withdrawn [1]. Given that flakes are…

I believe it is only withdrawn for further work on it.

Re: Nix is the ultimate DevOps toolkit

#204

Post by chriswarbo »

georgyo wrote: post #158
chriswarbo wrote: post #141

Earlier quoted context omitted.

> That is a gross oversimplification It's really not. I've used this successfully for Javascript projects (running npm and yarn), Python projects (running pip install), Scala projects (running sbt), Haskell projects (running cabal), Racket projects (running raco), Go projects (running go get), etc. It's pretty much like writing a Makefile, except we have to specify the buildInputs, and there are occasional annoyances…

>> which means you cannot do that method on environments you don't have full control. > Could you give an example of where that would ever be an issue? The only thing I can think of is hydra.nixos.org, but there's no way in hell such a derivation would be acceptable for nixpkgs, so that's pretty irrelevant (similar to how it's really easy to make a .deb package from a directory and a control file; but there's no way…

> production environment

> in production

Lol. If someone doesn't want to be executing random unverified binaries fetched from arbitrary online locations, then they shouldn't write such things in their build scripts.

That has nothing to do with Nix. The same goes for Makefile, or whatever.

Re: Nix is the ultimate DevOps toolkit

#205

Post by kaba0 »

mdoms wrote: post #162
domenkozar wrote: post #64

Earlier quoted context omitted.

That's another problem of documentation. The correct way is to search for packages as the following: https://nix.dev/tutorials/ad-hoc-developer-environments.html... And then install via: nix-env -iA attribute-name New Nix CLI as part of next release fixes that, but it's not out yet.

What an absolute nightmare. Just from reading this one comment thread I will never, ever try this tool. It sounds like there are a thousand ways to achieve a given task and no one can agree which one is "right", but everyone can agree that the way blessed in the official documentation most certainly isn't.

You are free to draw conclusion from 2 comments, but it is not too wise.

It is most definitely not a Windows Store one click user-friendly tool, but it is infinitely powerful, allowing you to run only one specific app with even something like a patched libc, upgrade the system and rollback wherever you want, it is the only package manager that doesn’t leave lingering files all around your system.

Re: Nix is the ultimate DevOps toolkit

#206

Post by ruuda »

madjam002 wrote: post #30

Has anyone explored CD tooling with Nix? And I don't mean the deployment of NixOS machines themselves (NixOps, deploy-rs, etc), I mean actually using Nix for deployment tooling and orchestrating deployments using the Nix language. I am yet to find any posts about this or any tools, but have had great success with a small hand rolled tool that essentially lets me decoratively describe cloud resources, parts of my appl…

What we do at Channable is build our packages with Nix, push them to Cachix, and record the Nix store path. (CI does that automatically for release builds.) Then we use Ansible to declare that that is the store path that we want to realize on the appropriate servers. Our packages contain an "activate" script that updates symlinks in /usr/bin, or systemd units. Ansible calls this script after realizing the store paths. We have some functions written in Nix to help writing these activation scripts, and Nix makes it easy to import them from a Git repository, so we have it in one place and import it in all of our repos. We are now moving towards CD by automatically running Ansible in some cases.

Re: Nix is the ultimate DevOps toolkit

#208

Post by ruuda »

skratlo wrote: post #142

Even though the article sounds like it's written by educated person, it puzzles me that the author: > Installing packages with APT is not atomic: APTs updates files in-place one by one. Because we start Python processes many times per second, if one started during a deployment, it could import a mix of the old and new code. This regularly lead to puzzling bugs Don't you stop all your services in preinstall and start…

This part is about batch jobs that we start, not about daemons. The APT package would take about a minute to install, but some of these batch jobs are started by a user interaction, and we can't delay them for that long.

Re: Nix is the ultimate DevOps toolkit

#209

Post by brunojppb »

The article is very interesting.

Although until the middle of the article I could make little sense of it because I had no clue what Nix was (have never heard of it), until I reach the part where Nix was introduced. Seems to be a very interesting tool.

Re: Nix is the ultimate DevOps toolkit

#210

Post by doyouhearu »

va1en0k wrote: post #84
ninjin wrote: post #36

Earlier quoted context omitted.

Blindly going after dissenters and/or alternative opinions is never a good thing, which communities would that be? In the ones that I frequent Nix is still a bit of a fringe phenomena reserved for nutters such as myself. From inside the Nix community it is from my perspective far more relaxed than most OS communities that I have been a part of over the last two decades.

It'd be probably easy to guess which communities I mean, but I'd rather not name names myself and hope someone supports me with a datapoint to offset my personal paranoia. Lately I encountered quite a lot of software - fringe and weird of course, but numerous enough - that went for having Nix as the only way to be deployed, typically with a "reproducible" script that doesn't work already after a year or two. As nix f…

I'm quite curious, do people like you review your comment threads and consider how they look to others?

You made a pretty serious implication that Nix users are hostile, in the context of certain projects. Given that numerous people have indicated how helpful they've found the Nix community, someone prompted you for more details.

Instead of providing those details you wrote three rambling hand-waving, non-specific paragraphs that frankly, say nothing.

> that went for having Nix as the only way to be deployed, typically with a "reproducible" script that doesn't work already after a year or two

I mean, if you have no problem saying things like that given how ignorant they make you look, I guess maybe you don't care.

EDIT: It's funny because I can think of a distinct counter example, a couple months back a newcomer wanted to push Nix on other projects and the overwhelming feedback from the community was to not do that. My experience over many years differ severely with this insidious implication that Nix users are hostile (especially when your second post literally boils down to "I didn't understand Nix and couldn't be bothered".) I keep running into this mentality where people project negative emotions onto others when something winds up being non-trivial to pick-up, and I just don't get it.

Post reply on HN