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

My First Impressions of Nix

mtlynch.io

Post reply on HN
Print view View original

71–80 of 354 posts

Re: My First Impressions of Nix

#71

Post by spacesuitman2 »

>I see words like “flakes” and “derivations,” and I currently don’t know what they mean.

>So far, I don’t get how it’s deterministic.

To make nix deterministic you can specify a hash in non-flakes (or a git rev) for your dependencies, but flakes make this easier. When you "run" a flake (be it nix build, nix shell, nix develop), nix pulls the latest (if no explicit rev given in the flake.nix already) version of whatever is specified in flake.nix that it can find, and creates a `flake.lock` file that specifies the exact version that was used. This file is very similar to cargo's Cargo.lock, and specifies the exact version that was captured by ref/hash. The next time nix is "run", it uses the lock file to get the exact same version as it had previously.

One can develop a flake.nix locally, install, check if everything works, and alternatively change the refs in the lock file to make everything work. When this is done you can move the nix and lock file to another machine and get the same exact build there (with the exception of architecture differences).

Because you can put flake.nix and flake.lock inside of git, you can also share the exact same dependencies with other people using a repository. Whenever I see a repository using these I know that building will be a breeze because I don't have to do any dependency hunting.

Re: My First Impressions of Nix

#72

Post by scandinavian »

nrabulinski wrote: post #59
hfkwer wrote: post #56

Earlier quoted context omitted.

I don't know if it's deliberate or a communication/comprehension problem, but you're misquoting Django's release process https://docs.djangoproject.com/en/dev/internals/release-proc... > * Versions are numbered in the form A.B or A.B.C. > * A.B is the feature release version number. Each version will be mostly backwards compatible with the previous release. Exceptions to this rule will be listed in the release notes.…

They clearly say “exceptions to this rule will be listed in the release notes” meaning that backwards compatibility is the rule. There’d be no exceptions if there was no rule hence I said they “should” be backwards compatible except for specific exceptions, which shall be noted in the release notes.

Not sure how this conversation is productive, but there's never been a X.Y release of django without noted backwards incompatible changes to my knowledge. Just imagine that djangos X.Y releases are semvers major releases, not much more to it than that.

Re: My First Impressions of Nix

#73

Post by scandinavian »

eptcyka wrote: post #67
scandinavian wrote: post #43

Earlier quoted context omitted.

I get what you are saying, but nothing you said works in practice for python packages, so not sure that I actually learned anything. Is it fair to summize that python applications with python dependencies do not really work well as nix packages and shouldn't be used?

What's the point of a minor version change if it's breaking? Does Django not have a versioning policy that enforces non-breaking changes between minor versions?

That's my fault for writing minor, as that's what it would be in semver. I should have written feature release.

You can read the release process here.

https://docs.djangoproject.com/en/dev/internals/release-proc...

Re: My First Impressions of Nix

#74

Post by sjamaan »

p-e-w wrote: post #13

I've occasionally encountered projects using Nix, and I've casually browsed the Nix and NixOS websites, but I still don't have a clear idea of what Nix is. Is it a package manager? A build system? An operating system? A container platform? A sandbox? An automation tool? Which widely used, existing software tools is it analogous to?

> Is it a package manager? A build system?

Nixpkg is a package manager, which uses the Nix programming language to describe dependencies and build steps. Like all package managers, it has components that could be called a "build system", but that's not its main focus.

> An operating system?

There's NixOS which is a Linux distro built on nixpkg. But you can also use Nix under other distros.

> A container platform? A sandbox?

Because nix is based on an underlying immutable store of installed packages (and doesn't rely on global system state), it is trivial to spin up a shell environment in which specific combinations of package versions are available without affecting any other shell.

This property allows it to be used as a lightweight alternative to containers, what people usually use Docker for: setting up an environment with well-known package versions that are the dependencies of your project.

As a very simple example, I've written a simple setup for running a chosen PostgreSQL version inside a directory: https://code.more-magic.net/ppq/about/. You could easily build this out by adding additional software, for example if you add Python and Django from Nixpkgs to this, you'd have a complete self-contained (or "sandboxed") dev environment.

When you're done developing on the project, you simple remove the repo and the entire environment is dropped too.

At work we use something like the above, with Java and Clojure and a whole bunch of other software, all completely self-contained. I never had to install any of it globally and didn't have to mess around with $JAVA_HOME etc.

Re: My First Impressions of Nix

#75

Post by Cloudef »

CapsAdmin wrote: post #26

I feel a little lost on nixos. Been using it for a while now on my main personal desktop and it's fine, but whenever I want to do something like running a python project (ml based ones for example), or compile software from source, I'm lost because I don't know what I'm doing. Most projects target Ubuntu, so I feel you need to know a lot about how nix really works to get them compiling, which is often not what I'm in…

You are supposed to use shell.nix, list the packages that the project lists in README and then you can use the normal README instructions. Unless you really care about doing it "pure nix way", (e.g. writing mkDerivation, which is waste of time in a dev env)

Re: My First Impressions of Nix

#76

Post by dpatterbee »

madjam002 wrote: post #35
CapsAdmin wrote: post #26

I feel a little lost on nixos. Been using it for a while now on my main personal desktop and it's fine, but whenever I want to do something like running a python project (ml based ones for example), or compile software from source, I'm lost because I don't know what I'm doing. Most projects target Ubuntu, so I feel you need to know a lot about how nix really works to get them compiling, which is often not what I'm in…

I've used Nix for 5 years now and use it heavily in production, and in my opinion, just do what works for you. If you try and use Nix 100% "correctly" then you'll end up like the countless other people who tried Nix and failed. Especially for toying around in dev environments, be pragmatic and take advantage of its amazing strengths, but if distrobox lets you enjoy using NixOS and speed up your workflow, so be it. He…

How are you managing docker compose with nix? Individual docker containers are easy to manage with `oci-containers`, but there's no obvious way for compose. Unless of course you're just writing the systemd configs in nix.

Re: My First Impressions of Nix

#77

Post by matklad »

scandinavian wrote: post #37

Now that we have another Nix post, maybe someone can enlighten me about something I've been wondering about. I'm one of the maintainers of a popular django application. Someone made a nix package of the project, but we've now twice gotten invalid bug reports from people using the package because the package depends on "django_4" and whenever someone updates that nix package, the package for our project breaks. Of cou…

I am not an expert, but here’s my attempt at a useful comment.

On the highest level, `nix` is an alternative build system. So, if someone packages your app with `nix`, there’s now extra work to keep that working, and it’s on the packager to keep it working. If they packaged your app such that it’s using different dependencies than those required, that’s a bug in the package. As a maintainer, you can help here by making it clearer what versions are accepted, and by making it easier to run the tests for a package.

If we open a black box, there are two things in play here: Nix-the-build-system and nixpkgs package collection.

The build system is very open ended and can specify all dependencies precisely, but it’s on the user to define what that means exactly.

nixpkgs is a coherent collection of nix packages, a bit like a Linux distro. In particular, it _generally_ has one version of each package, and there’s some testing to make sure that all the packages work together.

Now, to package a Python app with Nix you can either pull dependencies from nixpkgs, in which case the situation would be similar to, eg, packaging for Debian.

Or you could create a hermetic environment, where an app gets an isolated copy of dependencies, specific just to the single app, a situation similar to using virtual env.

It sounds like what happened here is that your app got packaged in the fist way, but actually it can work only in the second way. I assume you do specify specific compatible version of Django somewhere, and if a package (be it .deb, .rpm, or .nix) doesn’t respect that, that’s a bug in the package.

Hope this helps!

Re: My First Impressions of Nix

#78

Post by the_gipsy »

otabdeveloper4 wrote: post #60
scandinavian wrote: post #37

Now that we have another Nix post, maybe someone can enlighten me about something I've been wondering about. I'm one of the maintainers of a popular django application. Someone made a nix package of the project, but we've now twice gotten invalid bug reports from people using the package because the package depends on "django_4" and whenever someone updates that nix package, the package for our project breaks. Of cou…

nixpkgs doesn't use requirements.txt for whatever reason. (That reason probably being the utter brokenness and braindead state of Python packaging; Node packages work much better.)

You can package simple python projects, but as soon as there are too many huge deoendecies that use CPython and whatnot, it becomes impossible to generate the nix derivation. I just use imperative python-venv + pip install on those.

Re: My First Impressions of Nix

#79

Post by Cloudef »

mindwok wrote: post #30
nittanymount wrote: post #6

planning to learn/use ansible, wonder if Nix is ready to use ? have most functions/features ?

If you're planning on using Ansible for your job or to administer Linux systems, then stick with Ansible. Nix is very niche and you aren't going to see much return on investment until adoption is significantly higher, and I'm not sure that will happen in its current state. That being said if you want to learn Nix for its own sake or because it is awesome, which it is, then have fun!

Nix is gonna save your sanity in the long run however, compared to the ansible mess you eventually end up with.
Post reply on HN