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

131–140 of 354 posts

Re: My First Impressions of Nix

#131

Post by SuperSandro2000 »

hamandcheese wrote: post #54
scandinavian wrote: post #48

Earlier quoted context omitted.

> 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…

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

There isn't one but we are not collecting multiple package versions for no reason and since python itself cannot well handle multiple versions of packages they are only allowed outside of pythonPackages where all end user applications should live.

Re: My First Impressions of Nix

#132

Post by SuperSandro2000 »

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?

> 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, applications that are properly maintained work as they should and this can be ensured with tests and e2e tests.

Re: My First Impressions of Nix

#133

Post by Foxboron »

toastal wrote: post #85
ghuntley wrote: post #3

easiest 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,…

> reproducible builds

fwiw, NixOS does not support reproducible builds as defined by the Reproducible Builds project. They support reproducible environments/configuration/deployments or how you want to describe it.

Re: My First Impressions of Nix

#134

Post by SuperSandro2000 »

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?

Yes

> A build system?

No

> An operating system?

Thats NixOS

> A container platform?

nixpkgs has functions to build them

> A sandbox?

No

> An automation tool?

Yes and no

> Which widely used, existing software tools is it analogous to?

Arch Linux plus Haskell plus Ansible plus better

Re: My First Impressions of Nix

#135

Post by SuperSandro2000 »

sjamaan wrote: post #74
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 s…

> Nixpkg is a package manager

*Nix

Re: My First Impressions of Nix

#136

Post by prox »

hamandcheese wrote: post #23
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?

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?

Re: My First Impressions of Nix

#137

Post by SuperSandro2000 »

troupo wrote: post #5

> A lot of Nix documentation I’ve found says things like, “Simply add these lines!” > Huh? > Which file? And where in the file do I add those lines? This issue is prevalent everywhere . Even the best documented projects fail into this trap almost immediately.

> Which file? And where in the file do I add those lines?

/etc/nixos/configuration.nix if you haven't structured your config differently.

> And where in the file do I add those lines?

Consult `man configuration.nix` or search.nixos.org

Re: My First Impressions of Nix

#139

Post by SuperSandro2000 »

stayfrosty420 wrote: post #91

Nix reminds me about that xkcd comic about standards. It seems to be to be solving a problem solved in a much better way by other alternatives with the mindset of IT from a bygone era. I may just not really be the target demo, or maybe am just a huge idiot, but I struggle to see the appeal, especially when you hear about the occasional horror stories about complex and/or broken environments, or the vim-like overhead…

I don't know of anything before nix comparable to it but I happily learn something new.

Re: My First Impressions of Nix

#140

Post by the_gipsy »

goodpoint wrote: post #128
the_gipsy wrote: post #108

Earlier quoted context omitted.

Yea python is the exception. Go, rust, nodejs, have been easy to get running with specific versions and dev envs .

...and yet there's tons of Python packaged in traditional distributions including Django. Nix promises to solve exactly this problem... so it's not clear what the real benefit of Nix is. EDIT: a rain of silent downvotes?

Nix hasn't been a benefit when working with python for me, but again, python is the outlier. It has been a benefit for projects in other languages.

I guess the reason is because python packaging/tooling varies wildly between projects, and there are a lot of bindings.

BTW a colleague was setting up the python project on a non-nix machine, and also had problems with dependencies, and ultimately had to do some nasty workarounds (disabling deps/features). To me, it seems endemic.

Post reply on HN