Hacker News Reader

The thing about Nix is that it's the first project, as far as I know, that tries to solve the problem of package management with a fundamentally different approach. Most of the solutions to date were just okay: they worked with a tolerable degree of failure.

A solution that works good enough is often a serious obstacle for developing a solution that works really well. E.g. Unix works just good enough to preclude the adoption of a new paradigm in OS'es such as Plan 9.

Treating packages like immutable values sounds like a genuinely new idea. So what I think is that people don't go "this seems better than my current development toolchain", instead they think that the idea that underlies Nix might result in disproportionately more reliable tools in package management. That's worth fussing about.

Disclaimer: I am not associated with Nix in any way.

The first but not the last, there is also Guix the package manager and GuixSD the system distribution, which is written in Scheme, as well as all the package definitions. For lispers it is heaven.

(Guix is based on Nix, by the way.)

I am assuredly a "lisper" and I really don't want to use anything based on Nix. I really dislike how statically linked executables are not portable on Nix. I'm less upset w.r.t. dynamic library management.

I am sort of curious. What problems are you having with package managers that building decent packages wont solve ?

> As much as I criticize Maven, I'm not sure what this process buys you over maven except... well... what DOES it buy you over Maven dependency management?

I agree that using Nix doesn't make sense for application development where all the dependencies are resolvable within the language runtime. (Provided the runtime itself can be well-specified in the project configuration and the language's dependency management system defaults to exact immutable declarations.)

But throw in a dependency on Redis and Postgres, and you get into territory where traditional tools fall over pretty quickly, especially if different branches of your codebase depend upon different versions of Redis.

Personally Guix is more interesting to me as a way to keep my own stuff declarative rather than for sharing across a team of developers. But the cost doesn't seem too high if your application has external dependencies which traditional tools suck at; I've felt that pain and it isn't pretty.

> But throw in a dependency on Redis and Postgres, and you get into territory where traditional tools fall over pretty quickly, especially if different branches of your codebase depend upon different versions of Redis.

Surely you would just depend on the driver, which is most likely going to be written in your high-level language.

A better point may be languages which rely a lot on C libraries (think Ruby and Python), and where having something like pip won't magically install the ImageMagick dependency your software needs.

The driver's not much good on its own.

Traditional dependency systems force you to track the version of the server itself outside the project's configuration.

So? This kind of service often sits on a different box anyway in production.

I'm not sure what point you're making. Are you saying it's not important to run the same version of all your dependencies in development as in production?

I'm saying that in production, your application will likely connect to a database on a remote machine, which may or not have the same version as the one you packaged and you use for local development.

It's very strange to imagine that you'd host a DB in a conceptually local manner to application services. This couples things in a way that's very awkward for scaling. Even if you're not using containers, you almost never organize deploys this way outside of beta/dev environments.

And if you were to make such a decision, then you'd capture it in the closure required to run the code you built, so you'd sort of bake in the inclusion of those services into any deploy of your code, using Nix's philosophy.

Or am I misunderstanding you?

What I'm saying is that you should have a nix package for your application and one for your database server. Whether these run on the same machine or not is a question for how they're deployed, but it should be the same package that's pulled in by the production recipe and the dev recipe in any case.

Nobody's used cabal-dev in Haskell-land for ages. Cabal has had native sandboxing since mid-2013 and Stack is a more recent alternative.

I'd argue Nix is nicer for everything but Haskell because the way Nix thinks about versions doesn't fit projects as neatly as one would think. As a Linux distro it's nifty (fully systemd-ified).

Cabal sandboxes have "just worked" since release in my experience (my own, plus hundreds of IRC users I've helped).

Sure, the last time I deployed Haskell for a paycheck it was still cabal-dev. I'm absolutely out of date there.

But I sort of struggle to imagine using NixOS to ship products, as it would mandate every dev maintain a comparable NixOS environment for development. In a world where even editor choice can be contentious and user-facing Linux only runs well on a small handful of machine types, this seems a little unfair.

You don't have to switch to NixOS; you can run the nix package manager on any linux distribution or on OS X.

https://nixos.org/nix/

https://nixos.org/wiki/Nix_on_OS_X

A development team has to standardize on some things. Everyone might use their own text editor, but everyone can't use their own dependency management system.

This does't actually answer any real criticism I leveled except...

> but everyone can't use their own dependency management system.

This is untrue. Different disciplines use different tools for dependency management and it's not clear to me that the world is crying out for a unification here. Golang developers use one, Nim developers use another. Java developers have different requirements still.

Let's look at a pair of closely related langauges, Clojure and ClojureScript. While we might want a uniform method for DECLARING dependencies, the specific mechanisms used to fetch those dependencies may (and possibly should?) be different.

I didn't say everyone globally, I said everyone on a development team, i.e. a group of people working together to build a product. Creating a reliable development environment for a team can be a PITA. That's why Vagrant, and more recently Docker, gained a lot of traction. People could use Nix to solve the same problem, like ris describes at https://news.ycombinator.com/item?id=10050681

I just have a hard time envisioning package management as the light and the hope for this problem, at least at the level of granularity offered.

As sciurus said, Nix can be used on other systems than NixOS. The package manager is the main idea, and the distribution is an extension of it to provide its benefits also for system configuration. The package manager doesn't touch your normal system file hierarchy at all; everything is isolated in Nix's own hierarchy; users can install packages without root; etc.

How does that actually answer the criticism though? You lose binary portability, you mandate Nix as a deploy AND dev target. You mandate that every development environment either is Nix-friendly OR that you're on the hook for writing said management.

And, as I've noted in the past, these packages people make as afterthoughts to product development are often broken. You end up welding your dev environment directly to your deployment environment and you complicate cross-platform builds quite a bit (closures cross-platform are, unless they have changed since early this year, not really a well-formed proposition).