Is it wrong for me to ignore flakes and home-manager until they become "officially" integrated into Nix?

I’ve been very content with NixOS, and it definitely meets all my goals to keep a consistent and declarative upkeep with my various computer devices.

I’ve been looking to expand my configurations, such as integrating plasma-manager, home-manager, flatpak-manager, and other flakes and modules alike. HOWEVER, I do know that these thing are still being developed, and configurations and how to write and edit them may possibly change.

At the moment, I’ve been relying on a “bash script” I wrote to install all my flatpaks per device, and I just update all my bash scripts and configuration.nix files using Meld (such a useful tool).

Is it fair to continue doing things this way?
Am I overreacting by not diving into Flakes, Home-Manager, and alike? Am I missing out?

2 Likes

Flakes haven’t changed much since their introduction so I would say, in a practical sense, they are safe to use, however, they are just a layer of indirection that you could easily do without if you so choose. You can just use flake-compat if you want to use a particular flake while still sticking with only stable Nix.

Home-manager is an entirely different thing. It is its own project that is not intending to ever become an “official” part of the project, as far as I understand it at least. But it is a well supported community endeavor that you should be able to use very effectively with little effort.

3 Likes

I think you’re missing out a little bit on sharing code with a lot of Nixers, especially people who’ve come to Nix only within the last few years.

But I don’t think you’re wrong. Lots of people in the community, including some who have been generously contributing code for many years, aren’t interested in flakes or don’t like them. You don’t have to apologize for going with what works for you. :person_shrugging:

As in not sharing my config.nix via GitHub?

My scripts and configs are fairly simple, and just install things that I want to have on a computer. I don’t think I’ve done that much, besides compile a list of things I want installed, and have each computer share the script via Google Drive, to replicate the same and quick installation.

Regarding Flakes, I think it’s a very valid decision to not be using it in its experimental status, and I’ve been doing that without problems so far. While Flakes do add certain conveniences, you can do pretty much everything without Flakes. In the end it is (or rather, supposed to be) just a layer above stable Nix (though through its poor design choices it actually makes it worse in some ways).

13 Likes

I also mean consuming code that others expose as flakes, which is pretty convenient with flakes enabled. You can use flake-compat for that, if you want, though. It’s convenient to have a standardized interface for that, as imperfect as it may be.

In practice I’ve been taking the position that flakes don’t exist until they’re in the manual. It’s been fine. The most noticeable downside has been the inability to respond to the numerous help requests from people using pre-release flakes.

6 Likes

You are kind of wrong to only ignore the flakes until they are declared stable, as long as you don’t have any use for them, don’t use them, and you can just import the code directly or at worst with flake-compat most of the time.

nix-env -i has been there almost since the very beginning, is stable, is documented, is not deprecated due to opposition to deprecation, but still a horrible idea to use, after all… so base you usage decisions on what you need and not what has been (maybe even correctly, but there is never a guarantee) declared officially.

Home-manager is probably as stable as NixOS and Nixpkgs (which also have some code churn), doesn’t need flakes per se, and provides features that you might or might not want to use anyway.

And yeah, Nixpkgs is not a perfectly stable interface either, so if you do have a use for flakes, I guess it won’t be that bad of extra churn?

1 Like

Not using Flakes doesn’t mean one has to use nix-env. There’s nix-shell to get programs temporarily and NixOS/home-manager for more permanence. I believe it’s a fairly universal opinion that nix-env should generally be avoided. In fact there’s an active effort to remove nix-env from the manuals.

Similarly, there’s also no need to use nix-channel. There’s various other ways of getting Nixpkgs in a more declarative way. And for NixOS my recommendation is something like this.

10 Likes

As someone who does use nix-channel and has never used niv, what are the advantages of using the latter to manage Nixpkgs in the context of NixOS? The niv readme covers a lot of things that don’t seem relevant to that use case.

Definitely — I just wanted to give a definite example that something being stable might still be OK not to use ever.

1 Like

FWIW, nix flakes are in the nix manual.

In general, sometimes when you have a reference, you want to ‘lock’ the precise revision of that reference. e.g. in Docker, sometimes it’s convenient to use the :latest tag, but sometimes you want to reference the exact image digest. (Or in git, the branch name is convenient to use, but sometimes you want the precise hash).

Nix-channel more/less provides a way to have a convenient reference to some nix code somewhere… but, the list of nix-channels is essentially ‘state’ that you have to setup per user, and there isn’t a convenient way to ‘lock’ the reference (such that you can get the reference somewhere else). – So e.g. you might want to reference <home-manager> in your nix codebase, but nix-channels don’t provide a convenient way for ensuring that home-manager has the same revision on one machine vs the next.

One thing Nix flakes provide is a standard way to manage dependencies like this. Niv is another way to solve this.

1 Like

Ignoring flakes is fine. Home manager is an optional “use” of Nix that lets you manage your user environment similarly to how NixOS lets you manage your system. I personally think home manager is very useful and recommend it.

No. Use what you want. Use what you feel comfortable using.

And I’d add this: doing it this way makes your experience this much more valuable. The more you make use of the ecosystem in a particularly different way, the more varied your knowledge and experiences will be. Monocultures are bad.

For the record, been using NixOS daily since early 2017, have not used Flakes, have never used Home Manager. I don’t feel like I’m missing out on anything, though I did implement alternatives to the problem spaces.

5 Likes

with nix and NixOS I just tend to think of a motto from the perl folks: There’s More Than One Way To Do It and that’s what makes NixOS et al so great. I didn’t use home manager for many years and finally started one day and it’s been fine and I use flakes but in a way that works with channels allowing me to keep using “classic” commands.

“wrong” what does that mean? I don’t like phrasing the question like this.

If those projects don’t solve problems you have, then there is no reason to look into them in the first place unless you are curious and adventures and want to learn something new.

For me flakes solved managing channels by hand which is beginning at two NixOS machines a rather fulfilling chore and at the same time projects provide a more uniform interface including them in my configuration. Before every project did it differently and not always provided a way to not evaluate yet another nixpkgs which was a big annoyance for me.

I frankly don’t really care if flakes are experimental or not or if they change next week, month or year. I usually run the latest experiments like seen when testing Plasma 6 and when configuring things declaratively and being able to remove those experiments again without leaving trails in my entire system, then they are a less less experimental and easy to use.

I stopped using Home-Manager when I ran NixOS everywhere. For me there was no value in using it and only more chores to update it, fix evaluation errors especially when the documentation changed rapidly and waiting on upstream commits in subprojects which couldn’t be overwritten with flakes because HM does flakes wrong.

3 Likes

I’m very curious about this. Got any links to issues or something like that?

No, it isn’t wrong. Even if flakes were stabilized, it still wouldn’t be wrong. You are the author of your configuration; How you compose the tech stack is ultimately your decision for your own reasons. Niv? Flakes? Home-manager? Stylix? Just to name a few tools and libraries. It isn’t wrong for you not to use these and it isn’t wrong for you not to use NixOS or even Nix. That being said, it also isn’t wrong for you to use “unofficial” projects. I do think that you stand to benefit from using home-manager, and I do recommend it; But, I also recommend you investigate directly and discover whether or not that’s true for yourself. This is up to your own judgment for whether it’s fit for use, as with any of the other aforementioned tools.

I expect that you should judge these things in the same fundamental manner in which you would judge the utility of any thing, even non-software and non-tech things. I imagine that the most basic criteria are something like “does it solve a problem I have,” “does it do it better than the known alternatives,” and “is it worthwhile to pursue that benefit” or otherwise put: “is the added benefit greater than the cost of implementing this solution.” Maybe I’m wrong and you have a totally different way of thinking about that, and that’s fine too.

Just an fyi: I’m fairly confident that there is no intention to bring home-manager into NixOS proper. It will remain it’s own separately factored project. So, if you plan to wait on it becoming “official,” you’ll probably be waiting forever. Also, home-manager can be used without flakes, so there’s no need to worry about adopting them together.

2 Likes
1 Like