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

Why We're Moving on from Nix

blog.railway.com

Post reply on HN
Print view View original

101–110 of 144 posts

Re: Why We're Moving on from Nix

#101

Post by Nullabillity »

baobun wrote: post #82
jchw wrote: post #23

Okay I'm a Nix enthusiast but you'll have to trust me when I say that I'm not criticizing them for moving away from Nix; it isn't that strong of an emotional attachment. However, I'm not really sure I understand some of these complaints and they really could use more explanation. For example: > The biggest problem with Nix is its commit-based package versioning. Only the latest major version of each package is availa…

I think the part that's easy to miss is that their users are devs who will want to specify their own dependencies and versions for arbitrary packages. The way nix works with the way nixpkgs is structured, pinning a version of any package means pinning a commit of the entire nixpkgs tree. Since package builds of node/python/ruby packages depend on stuff outside of the package dir in the tree, you need that mapping bet…

> Since package builds of node/python/ruby packages depend on stuff outside of the package dir in the tree, you need that mapping between versions and commits.

> Using nix without nixpkgs may be fine for more scoped use but seems hard to justify for a platform like Railway.

Nixpkgs isn't all-or-nothing. You're right that Nixpkgs itself rarely packages more than one version of something, but the standard approach for "language package managers" is that you use a tool like crate2nix[0] which automatically generates pinned derivations for all of your dependencies.[1] For system dependencies which aren't covered by your language package manager.. you're basically in the same position as for something like Debian: you can either pull it from Nixpkgs (and give up control beyond "which Nixpkgs am I on?") or you can write/fork your own package. Or you can pull specific packages from specific Nixpkgs checkouts and splice them into your "main" Nixpkgs version as an overlay (though this is definitely getting into the Weird Territory(tm)).

[0]: https://github.com/nix-community/crate2nix

[1]: For example: https://github.com/stackabletech/secret-operator/blob/30f0eb...

Re: Why We're Moving on from Nix

#102

Post by [deleted] »

Nullabillity wrote: post #101
baobun wrote: post #82

Earlier quoted context omitted.

I think the part that's easy to miss is that their users are devs who will want to specify their own dependencies and versions for arbitrary packages. The way nix works with the way nixpkgs is structured, pinning a version of any package means pinning a commit of the entire nixpkgs tree. Since package builds of node/python/ruby packages depend on stuff outside of the package dir in the tree, you need that mapping bet…

> Since package builds of node/python/ruby packages depend on stuff outside of the package dir in the tree, you need that mapping between versions and commits. > Using nix without nixpkgs may be fine for more scoped use but seems hard to justify for a platform like Railway. Nixpkgs isn't all-or-nothing. You're right that Nixpkgs itself rarely packages more than one version of something, but the standard approach for…

[deleted]

Re: Why We're Moving on from Nix

#104

Post by sepositus »

eddythompson80 wrote: post #63
whateveracct wrote: post #56

Earlier quoted context omitted.

Nixpkgs isn't Nix and in production you rarely just use Nixpkgs verbatim. It's trivial to overlay whatever versions you want (including forks), and I'd say it's expected for any company in production to manage their package set. We are talking about a company full of professionals. If they need something obvious, simple, and default to manage their build - the core business function that turns their text into deploya…

> The industry is full of ineptitude though. While I disagree with the person you're replying to, I find your reply dismissive. I don't know the behind-the-scnene reasons for this, but I can very very easily apply a very similar situation to this from my experience. Nix is a full blown functional programming language along with a very rich (and poorly documented, niche, only second to C++ template in error comprehens…

Wow, this is literally the story of my team. Luckily there’s enough autonomy for us the escape the gravitational pull of the few remaining evangelists, but this is essentially what led us to this point.

Re: Why We're Moving on from Nix

#107

Post by kesor »

jchook wrote: post #105

Fascinated by so many replies of "actually Nix does this just fine, you just have to be an expert like me"

When a company is writing all of their technology and business using, lets say JavaScript. And then they come here and post about them switching to some NIH home-brewed language instead because they couldn't understand how functions or arrays work. That is not a problem with the people commenting on their stupidity.

Re: Why We're Moving on from Nix

#109

Post by rgoulter »

foooorsyth wrote: post #26

>The biggest problem with Nix is its commit-based package versioning. I am naive about Nix, but... ...isn't that like...the whole selling point of Nix? That it's specific about what you're getting, instead of allowing ticking time bombs like python:latest or npm-style glibc:^4.4.4 Odd to attach yourself to Nix then blog against its USP.

> > The biggest problem with Nix is its commit-based package versioning. > ...isn't that like...the whole selling point of Nix?

Not quite.

That sentence is definitely the most ... discussion-worthy comment in the blog.

To my understanding, OP wants to write a tool to make it easy for use cases like "use ruby 3.1 and gcc 12 and ...".

The main Nix repository is nixpkgs. Nix packages are source-based, so the build steps are declared for each version. To save maintenance effort, nixpkgs typically only maintains one version of each program.

I read OP's "commit-based package version" phrase to mean "if you want ruby 3.1, you need to find the latest commit in nixpkgs which used ruby 3.1, and use that nixpkgs revision". -- Although, worth noting, this isn't the only way to do it with Nix.

Though, regarding 'commit-based versioning' as Nix's USP? I'd say that's also a reasonable description, yes. (By pinning a particular revision of Nix, the versions you use will be consistent).

Re: Why We're Moving on from Nix

#110

Post by gf000 »

dleslie wrote: post #52
jchw wrote: post #23

Okay I'm a Nix enthusiast but you'll have to trust me when I say that I'm not criticizing them for moving away from Nix; it isn't that strong of an emotional attachment. However, I'm not really sure I understand some of these complaints and they really could use more explanation. For example: > The biggest problem with Nix is its commit-based package versioning. Only the latest major version of each package is availa…

I don't use Nix, however this seems dismissive: > While Nixpkgs is an amazing resource, Nix != Nixpkgs. If Nixpkgs is the default and alternatives require additional research and effort then for most users it _is_ Nix. > That doesn't make any sense. You can literally just split them into separate layers in whatever arbitrary fashion you'd like. The built-in Nixpkgs docker tooling has some support for this even. Is th…

> If Nixpkgs is the default and alternatives require additional research and effort then for most users it _is_ Nix.

This is not what parent commenter is getting at. Nix itself is a deterministic build tool. There is also a package manager built on top which uses a large collection of nix files to describe each package - this is nixpkgs.

They use the same primitives, but the same way you don't just yolo your node/rust etc build versions to whatever your OS comes with and use a lock file, you also want to have more control over the exact versions and thus may use something other than what nixpkgs packages. Especially that it makes it easy to override any property of your dependencies, unlike any other tool out there.

Post reply on HN