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

61–70 of 354 posts

Re: My First Impressions of Nix

#61

Post by ruuda »

scandinavian wrote: post #43
hamandcheese wrote: post #41

Earlier quoted context omitted.

It seems like Nixpkgs aims to minimize the number of package versions in use at one time. Not just nix, most package managers do, it seems (i.e. you wouldn't expect to find different minor versions of Nginx in Debian, would you?) So by that same logic, there is only one version of Django 4. It is definitely possible with Nix to use the precise versions of what's in your requirements.txt, but I'm not sure if the Nixpk…

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?

No, that is not a fair summary; Nix is the nicest way to manage Python packages that I have found thus far.

Re: My First Impressions of Nix

#62

Post by globular-toast »

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…

> Of course we, like all other python projects, don't support using other dependency versions then the ones in the requirements.txt file. So when someone just uses a different minor version of django, stuff breaks

That sounds wrong. A Python package should not have a requirements.txt file at all. A requirements.txt file is for "freezing" and fully reproducing an environment (ie. in a virtualenv or docker container). This is useful for certain applications like deploying services or sharing notebooks etc. It is not for packages. A package should document its requirements via setup.py/pyproject.toml and do so in the loosest way possible. Django uses semver and Django apps don't generally need to pin to minor versions.

Stuff like this is why people think Python packaging is worse than it really is.

Re: My First Impressions of Nix

#63

Post by rowanG077 »

dottedmag wrote: post #39

> Using VS Code Remote SSH on NixOS systems This is the main of issue with Nix and other niche distributions: they are new operating systems, with their set of file layouts, package managers, and even syscall variations. Linux ecosystem is awfully fragmented. If you ever want to use any software outside of your not-very-well-walled-garden provided by distribution authors, you have to hope your operating system (that…

I don't see how NixOS doesn't provide 2.

It's extremely easy to apply patches.

Re: My First Impressions of Nix

#64

Post by reuben364 »

globular-toast wrote: post #62
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…

> Of course we, like all other python projects, don't support using other dependency versions then the ones in the requirements.txt file. So when someone just uses a different minor version of django, stuff breaks That sounds wrong. A Python package should not have a requirements.txt file at all. A requirements.txt file is for "freezing" and fully reproducing an environment (ie. in a virtualenv or docker container).…

With my ignorance of the python packaging ecosystem, I was always under the impression that requirements.txt was the version constraints, not the lock file.

Re: My First Impressions of Nix

#65

Post by thorvaldsson »

nittanymount wrote: post #6

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

I got into Ansible around 8 months ago and wrote up a blog post with detailed steps, and a companion repository, about how to get started with using it. The blog post goes into how to setup everything needed for Android development via Ansible.

Perhaps, if you decide to take a look at Ansible, it might help with getting started https://hth.is/2023/01/02/android-ansible/

Re: My First Impressions of Nix

#66

Post by ryangibb »

> When does the determinism happen?

> When I specified packages to install, I didn’t specify an integrity hash, let alone a version number. If I ran the same Nix configuration a year from now, I assume I’d get a different system because it would install different versions of the vim and curl packages I specified.

That would be from the Nixpkgs [0] instance obtained from a Nix channel [1].

Nix flakes [2] provide an alterative way to specify inputs which pin them in a `flake.lock`. This allows things like Nix expression caching due to hermetic evaluation (as opposed to just builds being hermetic).

[0] https://nixos.org/manual/nixpkgs/stable/

[1] https://nixos.org/manual/nix/stable/package-management/chann...

[2] https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3...

Re: My First Impressions of Nix

#67

Post by eptcyka »

scandinavian wrote: post #43
hamandcheese wrote: post #41

Earlier quoted context omitted.

It seems like Nixpkgs aims to minimize the number of package versions in use at one time. Not just nix, most package managers do, it seems (i.e. you wouldn't expect to find different minor versions of Nginx in Debian, would you?) So by that same logic, there is only one version of Django 4. It is definitely possible with Nix to use the precise versions of what's in your requirements.txt, but I'm not sure if the Nixpk…

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?

Re: My First Impressions of Nix

#68

Post by qazxcvbnm »

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…

Hopefully this sort of issue will be addressed more satisfactorily when content-addressed stores find general usage.

Re: My First Impressions of Nix

#69

Post by crubier »

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…

Memoization is state. As a functional programming maximalist myself, I know it hurts a little bit, but still, Caching/Memoization is statefulness.

That said, you are right that as a user of the system, that statefulness is abstracted from you and you don't have to worry about it (until some subtle caching bugs forces you to dive deep in the rabbit hole)

Re: My First Impressions of Nix

#70

Post by scandinavian »

globular-toast wrote: post #62
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…

> Of course we, like all other python projects, don't support using other dependency versions then the ones in the requirements.txt file. So when someone just uses a different minor version of django, stuff breaks That sounds wrong. A Python package should not have a requirements.txt file at all. A requirements.txt file is for "freezing" and fully reproducing an environment (ie. in a virtualenv or docker container).…

The application is not distributed via pypi, nor is it installed as a package and thus have no setup.py file.

> A requirements.txt file is for "freezing" and fully reproducing an environment (ie. in a virtualenv or docker container).

No, it's just for specifying which versions of packages should be installed by pip. There's no such concept of a lock file with pip. Poetry and the likes have lock files though.

Post reply on HN