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

231–240 of 354 posts

Re: My First Impressions of Nix

#231

Post by goodpoint »

lolinder wrote: post #168
goodpoint wrote: post #90

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

What makes you think that the versions specified in the requirements.txt aren't reasonable ranges? All OP is saying is that if you're outside the version ranges in requirements.txt then you're outside the supported range. It's literally in the name of the file—requirements.

> What makes you think that the versions specified in the requirements.txt aren't reasonable ranges?

Because that's what the parent wrote.

Re: My First Impressions of Nix

#232

Post by kaba0 »

thumbuddy wrote: post #157
lillecarl wrote: post #146

Earlier quoted context omitted.

You don't have to manage your system with NixOS to reap the benefits of Nix. It solves very real problems that very much exist, it might not exist if you're a one-man show deploying WordPress to GoDaddy though. Barrier to entry: 1. Run the nix installer 2. Enable flakes 3. cd project 4. nix run This ensures you run the package with every dependency except the kernel pinned to a hashed version. If dependency hell is n…

You're omitting the entire thing about learning how to write nix. Which is nightmare fuel even for FP fans.

Just find a project written in the same language that is already packaged and copy it, modify the name, version, source url, hash and that’s it.

It is one thing that is easier done from the top, instead from the bottom.

Re: My First Impressions of Nix

#233

Post by fbdab103 »

kaba0 wrote: post #230
xxpor wrote: post #219

Earlier quoted context omitted.

Almost everything here is valid, but iirc the last time I ran the nix installer I thought it offered a home directory based install now that doesn't require root.

You can use in theory something other than /nix, but then you have to recompile everything yourself. So not many people do if, not sure about it’s state.

I just dipped my toe into the Nix pool a couple of weeks ago, and there are instructions to use root to create a /nix and grant ownership rw to your user account. No further admin required, but everything else seems to work as if using the Nix root user method.

Re: My First Impressions of Nix

#234

Post by 0x69420 » 

    > Nix optimizes for local configuration
yes yes yes yes yes.

nix makes deployment feel bottom-up, not top-down. you understand how a system is constructed locally before you (optionally, if it's in your job description) graduate to doing devops stuff with it. that was the singular thing that hooked me; the functional reproducible stateless referentially-transparent cacheable stuff was just what kept me on board.

Re: My First Impressions of Nix

#235

Post by bketelsen »

lenova wrote: post #207

Coincidentally I came across Fleek this morning, which appears to be a simplified Nix abstraction? https://getfleek.dev/

(fleek author here) Fleek is a simplified wrapper around Nix Home-Manager, which is used to install and configure the apps that make up your $HOME and shell environment.

Re: My First Impressions of Nix

#236

Post by lolinder »

SuperSandro2000 wrote: post #194
lolinder wrote: post #153

Earlier quoted context omitted.

This is such a condescending attitude. What you mean is applications that are maintained the way that you and the Nix developers think an application should be maintained. It's incredibly naive for a package manager as ambitious as Nix to assume semver. I'm a big fan of semver myself, but the vast majority of software projects follow it imperfectly or not at all, and for good reason—it's nearly impossible to follow i…

Nixpkgs does not assume Denver that's why we run if possible the package's tests, our own tests and build dependent packages to make sure the most obvious breakages are noticed before things are even merged.

Ah, I thought you were saying that if we all just used e2e tests to ensure we didn't make breaking changes in minor versions, we'd be fine. I didn't realize you were talking about the downstream package's tests.

I do still take issue with your insinuation that it's the package maintainers' poor practices that are at fault here. The real world is a messy, complex place and "best practices" don't translate well from situation to situation.

OP didn't ask for their package to be included in Nix. Presumably OP's system works for them and for their use case, but whoever created the Nix package made assumptions that turned out to be flawed. It's not fair of you to say that those bad assumptions are OP's fault because their package isn't "properly maintained" and doesn't "work as it should".

Someone (you?) made a bad assumption. Don't cast blame for that on someone who only knows Nix exists because it sends phony bug reports their way.

Re: My First Impressions of Nix

#237

Post by toastal »

ghuntley wrote: post #124
toastal wrote: post #85

Earlier quoted context omitted.

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

Getting someone up and running with a flake.nix with a defined devShell is just as simple and probably requires less knowledge since it's not another tool bolted on. Making the env and CI reproducible should be seen more like a good stepping stone and you can take the next leap when ready since it can all happen in the same flake file rather than a separate YAML one.

The world is your oyster approach is skipping Docker and just running Nix on the server without the overhead of containers.

Re: My First Impressions of Nix

#238

Post by 40yearoldman »

duped wrote: post #186
lillecarl wrote: post #146

Earlier quoted context omitted.

You don't have to manage your system with NixOS to reap the benefits of Nix. It solves very real problems that very much exist, it might not exist if you're a one-man show deploying WordPress to GoDaddy though. Barrier to entry: 1. Run the nix installer 2. Enable flakes 3. cd project 4. nix run This ensures you run the package with every dependency except the kernel pinned to a hashed version. If dependency hell is n…

> Run the nix installer Ok and this requires root access, sets up some global directories under root, and a new user. Me as the administrator: why the hell do I need a new user and what is the nix store and what are the conditions that mutate it? (I know the answers to this question, but it's a barrier for people who give a shit). > Enable flakes What the fuck is a flake? Reads a bit... what the fuck is a derivation?…

[flagged]

Re: My First Impressions of Nix

#239

Post by lenova »

bketelsen wrote: post #235
lenova wrote: post #207

Coincidentally I came across Fleek this morning, which appears to be a simplified Nix abstraction? https://getfleek.dev/

(fleek author here) Fleek is a simplified wrapper around Nix Home-Manager, which is used to install and configure the apps that make up your $HOME and shell environment.

This is what I love about Hacker News: post about a random tool I found, and the author shows up! :-)

I came across your blog (and from that, Fleek) as I'm rebuilding my home WSL setup, and I just want a simple way to destroy and rebuild my distros and move my installed apps easily. Would Fleek be a good use-case for this?

Re: My First Impressions of Nix

#240

Post by [deleted] »

lolinder wrote: post #177
assbuttbuttass wrote: post #171

Earlier quoted context omitted.

You can think of the function inputs as: 1. All the package definitions in nixpkgs 2. Any external sources When a package is updated in nixpkgs, input #1 changes.

I mean, I get that, but that means that the reproducibility of my build depends on the whims of the nixpkgs maintainers, it's not a property guaranteed by the package manager.

[deleted]
Post reply on HN