[acgkmopvvgvmgv]

Nix and similar projects are all going to be eaten alive by immutable distributions, Flatpak and new projects - that might work just like Nix but get the user experience right, and make packaging and maintenance easier. And no I'm not saying they do the exact same thing, have all the same features or target the same type of users.

For the developer tools side I like what Shopify did but I would never recommend that to my employer. Too many moving parts and not enough people using it that I would feel safe about it.

[adkadskhj]

As a new NixOS user currently set up with home manager and flakes - i'd probably switch in a heartbeat if someone gave me a nice nix-like package manager that also handled dotfiles.

As much as i love the feeling of NixOS, i really want something like a Lockfile as seen in Rust (and other languages).

Ie if i could define a `Cargo.toml`, which includes versions of packages or `*` if i don't care - and then it gets built into a `Cargo.lock`, i'd be in heaven. Combine that with a great language backing the distro and i'd switch immediately.

As it stands, I hate nixlang, and while flakes is amazing i still dislike the single primary input approach to NixOS _(ie all the packages bundled together)_.

As an example of why i dislike that, i'm stuck on an old version of NixOS currently because when i tried to update the repo date - lots of packages changed in difficult to manage ways. X was crazy slow, Firefox was being wonky, XFCE was janky, etc. All my flakes.lock told me was that the hash of the repo was different.. yay.. hundreds of dependencies were different i'm sure, but no clue which ones, and no easy way to isolate the problems and just incrementally update.

Luckily flakes allowed me to rollback perfectly. Well, i still had some userland state from the newer applications that i needed to nuke, but i'm ignoring that for now.

Being able to more easily incrementally update specific dependencies would be amazing for me. As it stands i have no clue when or how i'll update my NixOS input version. Which is not a promising sign for my continued usage of NixOS.

[kaba0]

I don’t really understand your problem as in NixOS it is precisely the easiest to handle some packages from this repo and anothers from another. You can just add a single line of an alternative repo like altNixpkgs = “reference repo either by url or path” in the let in “block” and instead of pkgs.something just use altNixpkgs.pkgs.something.

Also, I usually manage my home packages separately from my global config. The easiest way to do that is probably by adding a different channel/path to your user’s nix-channels. I believe home-manager uses that. Alternatively you can also do the trick I mentioned in your home.nix file.

[adkadskhj]

> I don’t really understand your problem as in NixOS it is precisely the easiest to handle some packages from this repo and anothers from another. You can just add a single line of an alternative repo like altNixpkgs = “reference repo either by url or path” in the let in “block” and instead of pkgs.something just use altNixpkgs.pkgs.something.

Yea, i actually do that for a couple of my dependencies. My problem is there are dozens or hundreds in my OS that instantly upgrade if i change my `nixpkgs` ref. And i have no clue what version _any_ of those are at, off hand.

Eg lets say i want to fix my X - because when i updated my `nixpkgs` pointer Xorg was using a lot of CPU for some reason. There's no lockfile that says what version X is at, or what dependencies X is using or associated with. Is it one package? Is it a half dozen? I could open the repo and dig through the configs to locate it and _try_ to infer what the hell version it's at, and what dependencies it has.. and then find what they're at and so forth - but it's convoluted imo. Much easier in Cargo.lock, for example - something i've done dozens of times before.

In short, basically everything in my OS broke when i updated my nixpkgs ref, and it's non-obvious and maybe non-trivial to understand what versions everything is at. To incrementally try to un-screw my system when i change my nixpkgs.

As i move forward, any packages i install i'm tempted to bind them to very specific inputs. So that when i want to upgrade one thing, only that one thing changes. But this workflow seems difficult in NixOS. Despite it being the workflow that i want.

Well, maybe not difficult - but lots of LOC. Adding dozens of inputs just to change versions of stuff without breaking other things seems like a lot of work for a dependency management system.. imo.

[Ambroisie]

You can use the Nix tooling to show the diff between two derivations' closure.

I have a script which I use [1] after updating my Flakes to do just that : know what has been upgraded.

[1] https://github.com/nix-community/nur-combined/tree/master/re...

[kaba0]

Thank, I get it now. Not a solution but perhaps try git bisecting the working and non-working version. It’s never a good thing to hunt down a bug but when one has to, the immutable nature of nixos actually makes it a very handy process.

[casept]

Given that you already have flakeified everything, it's not that hard to pull in a different version of nixpkgs and cherry-pick packages from it. I have a (somewhat complex) setup utilizing this: https://github.com/casept/nixos-config

[adkadskhj]

Yea, i actually do that now. My problem is the dozens of packages i didn't hand pick all broke. So basically i need to hand pick everything. And in doing so, it feels like a lot more work than simply specifying what versions i want during the package install.

[kaba0]

I’m not too afraid of a niche being eaten alive by a slightly larger niche :D

Also, I don’t really see the value of flatpaks, they don’t solve the dependency hell problem (nix does) nor they are adequate sandboxes (be honest, linux has non-existent user-space security, it’s frankly terrible. And for some reason even flatpak is written in goddamn C in 2000+ something)

[circularfoyers]

Why do you consider flatpak as not having adequate sandboxing?

[takeda]

> For the developer tools side I like what Shopify did but I would never recommend that to my employer. Too many moving parts and not enough people using it that I would feel safe about it.

I'm not sure I understand you. In their case this became the standard dev environment. Everyone in the company is using it and the true benefit is that it makes development predictable. You only need one command to set up dev environment. He also mentioned that it is much faster than the old way.

[sph]

I'm out of the loop, what did Shopify do?

EDIT: ah, you're probably talking about https://shopify.engineering/shipit-presents-how-shopify-uses...

[takeda]

I hate that they mentioned about ru.nix, published it on github for short time and then unpublished it[1].

[1] https://github.com/Shopify/runix/

[pxc]

I think they wanted to avoid having people build on it before they stabilize its interfaces, since they still had some big changes planned. As I understand it, the plan is supposedly still to publish it at some point.

I hope that if that's true, they publish it soon, because its design is very relevant to ongoing changes in the ecosystem, and it could be a useful reference point. :(

[takeda]

I don't think it is. The talk was a year ago and it still isn't available.

I created my own version, based on (I think they did that too) on NixOS modules system.

But I'm wondering how it compares.

Actually looking at https://gist.github.com/burke/72ca46c80e57a25907a75611ee5eb6... I think their goal is slightly different than mine.

There's also https://github.com/hercules-ci/project.nix but it wasn't touched for a year now.