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

51–60 of 354 posts

Re: My First Impressions of Nix

#51

Post by hamandcheese »

henrydark wrote: post #40
microtonal wrote: post #24

Earlier quoted context omitted.

Just to elaborate a bit for those not familiar to Nix (slightly simplified to exclude recent support for content addressing). Nix work with derivations, a derivation is basically a data structure that specifies how a package is built. Derivations are normally not created by hand but using a function (eg. stdenv.mkDerivation ). When you ask Nix to build a package, it hashes a normalized form of derivation data structu…

I agree with everything but the last statement. This all comes down to: do you consider memoization to be state. I predict people's answers to this question will come from experience with memoization. Here's mine: I kept trying to get nix to build tensorflow locally, so that I would get the avx512 benefits of the big, but gpu-less machine I had. I hadn't realized some other derivation had already downloaded tensorflo…

Yes, you have unfortunately discovered that sometimes the hardware itself is an input that isn't always captured explicitly, but also isn't controlled for with sandboxing. Ideally enabling avx512 would be an explicit input to the tensorflow package, but based on your experience it sounds like this feature is detected during the build automatically.

I hope that issues like this get better over time thanks to projects like Trustix, which would make non-reproducibility like this more apparent.

Re: My First Impressions of Nix

#52

Post by rollcat »

imagineerschool wrote: post #27
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?

"Yes, it is." AFAIK It's each of those things, each unfortunately named the same.

We already have names like NixOS and nixpkgs at the top, and individual commands such as nix-env or nix-shell at a lower layer. Perhaps it would be beneficial to adopt official names for other components currently named "nix", such as nixlang (when referring to just the language).

Re: My First Impressions of Nix

#53

Post by nrabulinski »

hfkwer wrote: post #50
nrabulinski wrote: post #45

Earlier quoted context omitted.

Sounds like the problem is with Python maintainers who don’t understand that breaking changes should only be made between major versions. If that’s not possible though then as sibling comment said - you can override the dependencies and the nix maintainer should make sure the package works as expected

Sounds like the problem could also be with Nix maintainers who don't understand that "semver" is not a universal law of nature and that not all projects and ecosystems follow it. This kind of blanket dismissal can cut both ways. Semver (the website and "spec") was created in 2009 by some guy. It's not an RFC, a standard, or anything like that. Yes, it gained widespread adoption. Yes, the guy in question is a cofounde…

Except Django site says that a.b are feature releases which should be backwards compatible except for specific exceptions. If their software truly breaks “with every update to django_4” then it’s either a problem on Django’s side or a problem in how said person uses Django

Re: My First Impressions of Nix

#54

Post by hamandcheese »

scandinavian wrote: post #48
hamandcheese wrote: post #47

Earlier quoted context omitted.

> but nothing you said works in practice for python packages How do transitive dependencies in the Python ecosystem work, then? I assume Django works with multiple versions of python and bcrypt. I assume pandas works with multiple versions of scipy. Is there no semantic versioning? If everything requires an exact version, how do you prevent everything from grinding to a halt? > Is it fair to summize that python appli…

> How do transitive dependencies in the Python ecosystem work, then? Not very well. > how do you prevent everything from grinding to a halt? I don't have a good answer for you. > Is there no semantic versioning? You can read django release process here [1], not sure how it's relevant. I'm not the maintainer of django, but of a project using django. Would it be better if all software was perfect, had no bugs and used…

> not sure how it's relevant.

Well you said earlier that nothing I said works in practice for python packages. My only point is that it must work at some level in the python ecosystem, else the ecosystem would collapse.

Anyways, it sounds like you're unhappy that someone did a bad job packaging your application. That sucks. Elsewhere in this thread someone mentioned that there isn't a strict single version policy in nixpkgs, so this can probably be easily fixed. I'd suggest filing a bug in Nixpkgs.

Re: My First Impressions of Nix

#55

Post by nrabulinski »

cormacrelf wrote: post #46
mteigers wrote: post #38

Earlier quoted context omitted.

I'm curious if you have any pointers for whole Mac config with nix-darwin. This is something I've just started looking at and at the moment don't have much more than a nix-shell with some nice-to-haves. Any tips / tricks / guides are greatly appreciated.

Life’s short. Don’t waste it configuring nix-darwin.

As someone who has nix-darwin on their daily driver machine I can confidently say that I spent very little time configuring it and my config is almost in full shared between both NixOS and nix-darwin

Re: My First Impressions of Nix

#56

Post by hfkwer »

nrabulinski wrote: post #53
hfkwer wrote: post #50

Earlier quoted context omitted.

Sounds like the problem could also be with Nix maintainers who don't understand that "semver" is not a universal law of nature and that not all projects and ecosystems follow it. This kind of blanket dismissal can cut both ways. Semver (the website and "spec") was created in 2009 by some guy. It's not an RFC, a standard, or anything like that. Yes, it gained widespread adoption. Yes, the guy in question is a cofounde…

Except Django site says that a.b are feature releases which should be backwards compatible except for specific exceptions. If their software truly breaks “with every update to django_4” then it’s either a problem on Django’s side or a problem in how said person uses Django

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.

> * C is the patch release version number, which is incremented for bugfix and security releases. These releases will be 100% backwards-compatible with the previous patch release. The only exception is when a security or data loss issue can’t be fixed without breaking backwards-compatibility. If this happens, the release notes will provide detailed upgrade instructions.

Going from "mostly backwards compatible with the previous release. Exceptions to this rule will be listed" to "should be backwards compatible except for specific exceptions" is quite the stretch. There are no "specific exceptions": incompatibilities can be anywhere and you need to read the release notes to know where. In semver, a minor version increment is backwards-compatible, no exception, no ifs or buts.

If you want to shoehorn Django's release process into "semver", then act as if the product is called "Django 4". If the version is "Django v4.X.Y", then X is the major version number, Y is the minor version number, and there is no patch version. It should be version in Nix as "django4 vX.Y.0".

Re: My First Impressions of Nix

#57

Post by globular-toast »

hardware2win wrote: post #16
hamandcheese wrote: post #8

> Nix, on the other hand, does have a concept of state. If you make a one-line change to a 200-line Nix configuration, it doesn’t have to re-do all the work from the other 199 lines. It can evaluate the state of the system against the configuration file and recognize that it just has to apply the one-line change. And that change usually happens in a few seconds. The author seems to have some misguided ideas about Nix…

Functional?

Just in case: https://en.wikipedia.org/wiki/Functional_programming

Re: My First Impressions of Nix

#58

Post by Jedd »

My experiences with Saltstack and Ansible are inverted - I realise the comparison was only a casual aside in TFA, but the 'Ansible executed the idea better than Saltstack' comment invites so many questions, especially in the context of an article that dwells on how unpleasant Ansible is.

Ansible certainly defaults to slow, and I never got into the weeds for performance tuning it, but Saltstack felt fast, especially the example of 'install package foo' which he anticipated takes 15 minutes to run against one of his VMs using Ansible. I agree, that sounds unpleasant.

Others have noted the slight confusion about state (and where that state is or should be maintained), and certainly writing idempotent salt or ansible recipes takes some thought, just as writing performant recipes does. The 'have to rewrite everything' whenever Ansible releases a new feature doesn't sound right - perhaps I misunderstand the problem described there.

Author mentions apt, but ultimately sounds like they wanted something more container-y than a fat VM running a full GNU/Linux distro with managed packages + config files. In that light, the mention of Hashicorp - specifically Terraform & Nomad - felt tantalisingly prescient.

Re: My First Impressions of Nix

#59

Post by nrabulinski »

hfkwer wrote: post #56
nrabulinski wrote: post #53

Earlier quoted context omitted.

Except Django site says that a.b are feature releases which should be backwards compatible except for specific exceptions. If their software truly breaks “with every update to django_4” then it’s either a problem on Django’s side or a problem in how said person uses Django

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.

Re: My First Impressions of Nix

#60

Post by otabdeveloper4 »

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.)

Post reply on HN