planning to learn/use ansible, wonder if Nix is ready to use ? have most functions/features ?
If you have OSX, it's much more reliable and better option than homebrew, so there it would pay off immediately
My First Impressions of Nix
81–90 of 354 posts
Re: My First Impressions of Nix
#82Earlier 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?
> python dependencies do not really work well
Yes, that is exactly correct.
Re: My First Impressions of Nix
#83I'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?
> Which widely used, existing software tools is it analogous to?
It's kinda like Docker, but without the images/containers.
Docker solves two problems: distributing the same program everywhere, and running those programs using containers.
Nix solves the former problem. But, since it doesn't use containers, you can run the Nix packages without needing to worry about mounting into VMs or containers.
Re: My First Impressions of Nix
#84I'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?
Most of the above. - Nix is a tool for building and installing software. - Nix is a language for expressing how to build a package. Nix-the-tool reads expressions defined in Nix-the-language to know what to do. At the end of the day, this translates into normal commands that run in a sandboxed build environment. - Nixpkgs is a monolithic repository of 80000+ packages, defined literally as one giant expression in the…
[deleted]
Re: My First Impressions of Nix
#85easiest way to get up and running w/value in the nix ecosystem is https://devenv.sh and as time goes on use escape hatches to utilise more of nix ala https://nix.dev
Disagree. The larger selling point is Nix reproducible builds. Getting a reproducible developer environment is a start, but everything inside that “shell” is then mutable. Hiding Nix behind YAML is obscuring a tool, Nix, to make the entire build stateless—and that YAML can often be a stopping point where folks aren’t going ‘deeper’ to unlock the reproducible build part.
There are things it does that are very helpful, like enabling a PostgreSQL server without much setup, but other things like forcing certain language toolsets goes a bit too far—especially when those tools are already in Nixpkgs and setting up a base devShell provisioned with a few console tools is one of the easiest things to do with Nix the language already.
Re: My First Impressions of Nix
#86I use Replit a lot and it uses Nix.
I think everybody has a different idea of what they find intuitive or what they think of as being "good". Some people struggle with git for example.
As a tool writer (I wrote https://devops-pipeline.com), I want (command line) tools to be elegant and the command line tools to be obvious.
Re: My First Impressions of Nix
#87Now 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.)
> Node packages work much better
Are you sure about that? I haven't seen a node app built from source on nixpkgs yet. That includes Electron apps like Signal Desktop, which is a bit disappointing.
There is this article about trying to package jQuery on Guix:
Re: My First Impressions of Nix
#88Earlier quoted context omitted.
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.
Yeah I normally use oci-containers but for this workload the only supported method of installation is a `docker-compose.yaml` file.
I've just written a systemd service that does `docker compose pull` and `docker compose up -d --remove-orphans` with the compose file being written to the Nix store, works well.
Re: My First Impressions of Nix
#89[deleted]
Re: My First Impressions of Nix
#90Now 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.
That's really bad. You should always support reasonable version ranges.
> when someone just uses a different minor version of django, stuff breaks
That's why some people say that managing dependencies in Python is difficult and move to statically compiled languages.