SO FAR:
Let’s say I’m trying to install telegram in my nix via
nix-env -iA nixos.telegram-desktop
It’s not the best way to do it in the Nix’s declarative say. It’s been like this, because it’s just imperative approach.
WHAT IF:
Whenever we do that command the package name gets added into the nix-env-additional-packages.nix file and be taken as input / modules in other configuration files by DEFAULT.
I know this can easily be done via shell aliases etc. But the thing is why this couldn’t be the DEFAULT behaviour?
It’ll reduce the friction in learning and usage of nix making .
Coz it removes the behaviour of the command from being imperative to declarative.
Some might say this method isn’t even needed and may ask me to add files declaratively in config file. I agree that. But still people with habitual behaviour from other package managers and those who used such commands in some scripts for whatever reason, will still get benefitted from this default behaviour.
This way we can achieve from
“Declarative if needed and Imperative if needed”
to
“Declarative by default and Imperative to Declarative”
I want people’s facts and ideas on this suggestion.
Because it doesn’t make sense to do so. Many packages need more config than just “add it to a package list and be done”. And side note, nix-env itself is broken in many other ways.
Fundamentally if you don’t want to write code to configure your system, NixOS is not the distro to use (and that’s ok! Most people do not want to write code for this.)
@waffle8946 this is not just about NixOS though, but I agree that the native environment management UX is fundamentally broken and probably unsalvageable. A viable solution would be adding CLI commands to environment management systems that actually work, such as Home Manager, and enabling for them a first-class installation experience that doesn’t depend on Nix itself.
@ksvivek what you say is perfectly reasonable, just the point of attack should be something different. It should be fairly easy to build a prototype where you just add package names to some file that is imported by your Home Manager configuration.
I’ve said it multiple times now: Let’s stop considering Nix a package manager. At the surface it’s mainly a build and deployment system that happens to have some package management capabilities built in from ancient times. The package management use case is much better catered to by Nixpkgs and things like Home Manager. Nix itself is just an engine to do purely functionial programming with file system trees.
Oh. But whenever we do a declarative action in CLI, I just want it to be tracked in a declarative way as .nix files so it’ll be easy to import as packages if needed.
You mean imperative - and anyway, that’s my point: solely adding a package is usually the wrong thing to do. Pretending otherwise by changing the behaviour of nix-env is only masking the problem, not lowering the learning curve. What beginner users must start doing is searching for NixOS options first before trying to simply add a package to a list.
What I would personally prefer is an annoying warning when someone uses nix-env in an interactive shell, reminding them that they should be editing their config instead. (Though, that would annoy potentially legitimate users…)
And I doubt we are talking about non-NixOS, since the command in the original post mentions the nixos channel. Though maybe I’m wrong about that, I avoided nix-env enough that I don’t know the syntax offhand
But if we are talking about other distros, even the below would do the trick, if HM and/or system-manager are not a good fit:
I’ve sketched an alternative with flakes around here somewhere before, which is basically the same just using flake syntax to do it which gets 90% to the “simple package management but declarative” holy grail (as it avoids all the inherent nix-env pitfalls), just needs some CLI tool to make it easier.
Much like @fricklerhandwerk says, nix isn’t a good package manager, but it’s a pretty good engine for one - nobody seems to have bothered writing one yet, unfortunately (maybe nix-software-center? With the caveat that nixpkgs could use some metadata to determine what software is just installable without additional config).
You can still use the nixos channel on other distros just fine. The main difference is that the nixos channel goes through some extra CI to ensure that people can still boot their machines after updating, which doesn’t exactly hurt on other distros.
Makes sense. I agree with the part of warning like it’ll give in search.nixos.org when installing with nix-env. Depreciation I’ll suggest, but still to those who use it atleast should get a warning I believe.
So instead of just providing ways to tackle the imperative thing, the attack should be on its existence rather I believe.
But those who don’t want to deprecate it, may atleast benefit by tracking the changes.
If you track the changes, don’t you need a way to apply them elsewhere? Otherwise, what would be the point? At that point, wouldn’t you have your declarative approach with a tool to edit it?
I’d also like to have a better way to manage environments on Non-NixOS systems. Home-Manager is often too much for new users and the ergonomics of nix-env and nix profile are not terribly good. Plus, whenever a user searches himself, he finds all these frightening “don’t use this, it’s broken” notes. But there’s not really an alternative doing the same without NixOS.
Through nix-env you have access to channels. Lets look at nix profile instead so we don’t need to at least look at channels.
Now how would you find the source nixpkgs or any other source that the package was installed from? if you do nix profile install nixpkgs/release-24.05#hello, now the file must track the specific version this hello package came from. What if you do another nix profile install nixpkgs#python3? How would you update them?
Imho this introduces more problems than it’ll solve and eventually leads you to the opposite path of figuring out your source first, then listing packages you want from it (the way its done in home-manager, can be done without it as well with a few nix files)
I agree, nix profile works more or like nix-env, so it has the same issues, and sometimes it’s even worse.
For example: until recently you couldn’t remove packages by name (you’d have to specify a number which would change after each package removal, not fun).
With nix-env you used to be able to “update” a package by installing a newer package version over it; with nix profiles you can’t do that.
By the way, you can still use channels in nix profile:
I’d also like to have a better way to manage environments on Non-NixOS systems. Home-Manager is often too much for new users and the ergonomics of nix-env and nix profile are not terribly good.
You can use nix-env in a declarative fashion to manage an environment much like home-manager but without all the complexity of NixOS modules. See this:
