161–170 of 354 posts
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…
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.
Nix is absolutely awesome in that regard.
Possibly this is Ansibles biggest strength as well, as it feels incredibly simple to get going.
Salt has a much steeper learning curve due to both weird nomenclature and the infrastructure.
Nix is in many ways easy to use “on the surface” but quickly becomes hairy as you dive deeper.
Just my 2c having spent quite some time with all three.
Earlier quoted context omitted.
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…
So does this allow for different boot setups for NixOS? Say “webserver” or “office management” , “media streamer” profiles?
Earlier quoted context omitted.
> The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. That's simple: nix is a package manager and the language used by the package manager, NixOS is a Linux distro. > It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't…
Nix vs not Nix seems like a parallel to Infrastructure As Code (terraform for example) vs Cowboying the AWS Console. Is that a fair comparison?
Biggest drawback of ansible is that it is stateless and as such you can’t simply declare a desired system state and apply it. Nix is absolutely awesome in that regard. Possibly this is Ansibles biggest strength as well, as it feels incredibly simple to get going. Salt has a much steeper learning curve due to both weird nomenclature and the infrastructure. Nix is in many ways easy to use “on the surface” but quickly b…
Earlier quoted context omitted.
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: http://dustycloud.org/blog/javascript-packaging-dystopia/
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. 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.
Earlier quoted context omitted.
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.
It's a PITA but unlike pip and conda it's 100% reliable.
> 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…