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

121–130 of 354 posts

Re: My First Impressions of Nix

#121

Post by kaba0 »

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…

No package manager before Nix solved the whole problem at all. Nix is the first of its kind.

A good litmus test: install the gnome and the kde desktop envs on your linux system with your preferred package manager. Now remove both. Will you get back to a fresh install state? And it’s not even a hard problem yet.

Now how would it solve installing a second chromium browser that uses a patched libc beneath?

Re: My First Impressions of Nix

#123

Post by SuperSandro2000 »

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…

They don't need to use the same version of the Django package but Python dependency pins are often either way to tight and can easily be expanded or outright missing, so they often get ignored.

Re: My First Impressions of Nix

#124

Post by ghuntley »

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

i agree with some of your points but differ as follows:

getting an entire team or project up and running in less than 5 mins with devenv is a fanstastic introduction for folks who do not have experience with nix. devenv solves the “onboarding new developer in a couple seconds without having to learn nix” pain point.

the next step there is to migrate away from only using nix shell (via devenv) and go for making ci reproducible locally once folks are more comfortable with nix/less career risk for introducing new tech.

then the world is your oyster.

use build2dockerImage and start creating docker images that are reproducible and use them in production.

Re: My First Impressions of Nix

#125

Post by gonehome »

thumbuddy wrote: post #107
adamgordonbell wrote: post #92

Earlier quoted context omitted.

Explaining what Nix is seems like one of its biggest barriers to adoption. Part of the difficulty is it means different things to different people. My colleague spent a whole lot of time trying to answer this question and ended up with this: My main take away after spending some time learning about Nix is that it embraces the functional programming concept of a pure function. If I give a function a certain set of inp…

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. 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 really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…

This matches my experience with it so far. Extremely complicated and hard to understand, projects that use it have builds fail anyway except now with very hard to debug errors.

Re: My First Impressions of Nix

#126

Post by duped »

scandinavian wrote: post #70
globular-toast wrote: post #62

Earlier quoted context omitted.

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

> There's no such concept of a lock file with pip.

There's the --require-hashes flag and the ability to specify the hashes in your requirements.txt

Re: My First Impressions of Nix

#127

Post by SuperSandro2000 »

matklad wrote: post #77
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…

I am not an expert, but here’s my attempt at a useful comment. On the highest level, `nix` is an alternative build system. So, if someone packages your app with `nix`, there’s now extra work to keep that working, and it’s on the packager to keep it working. If they packaged your app such that it’s using different dependencies than those required, that’s a bug in the package. As a maintainer, you can help here by maki…

> packaging for Debian.

Not really, nix is way more flexible and more up to date and nix also often runs tests and different pythons cannot interfere with each other that easily. On a high level things are similar but the details are wastly different.

> Or you could create a hermetic environment, where an app gets an isolated copy of dependencies, specific just to the single app, a situation similar to using virtual env.

That could also be done with nix but is often not because upstream pin quality is often lacking.

Re: My First Impressions of Nix

#128

Post by goodpoint »

the_gipsy wrote: post #108
Filligree wrote: post #104

Earlier quoted context omitted.

And it does, for most languages. Python seems more difficult than average.

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?

Re: My First Impressions of Nix

#129

Post by SuperSandro2000 »

goodpoint wrote: post #90
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. 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.

> That's why some people say that managing dependencies in Python is difficult and move to statically compiled languages.

Yes, completely agreeing with that.

Re: My First Impressions of Nix

#130

Post by SuperSandro2000 »

the_gipsy wrote: post #78
otabdeveloper4 wrote: post #60

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.

> I just use imperative python-venv + pip install on those.

The whole point of NixOS is to manage this and to get rid of those manual steps that are error prone.

Post reply on HN