It's unfortunate that this is the top comment, as it might unfairly turn potential users off to Nix. Imperative command line installation of packages with nix is contrary the model of how it is supposed to work, and is deprecated. I've never used it once.
The thing is, it might be contrary to the underlying model of the OS, but it's how a lot of people want to do it.
To give a similar example: in the Rust programming language, dependencies are declared in a TOML file. While the dependencies are declarative, there's also a popular tool (that's being added to the main project) that lets you do
cargo add awesome-thing-rs
and add the dependency to your project, and edits the config file for you. That's it: no combinations to remember, no weird use cases, no unintuitive error messages, you just say "I want to add X" and then X is added.
Is it really that hard to add a word to a list in a config file? If this is what is stopping you, then you haven't yet understood how nix works or the value of nix. You could write a shell script in 5 minutes that would add and remove package names from a nix config file, but that's fundamentally no different from writing a tool to add #define lines in a C header file rather than just manually editing it. It's missing the point.
For me it is a context switching issue. If I'm reaching for a package it is because I was in the middle of something that needed it. I'm not sitting there thinking "What packages might I need some day?".
So if nix could allow me to get the tools I need without context switching that would be a great addition. I don't want to have to go edit configuration files just because I haven't installed some tool yet.
The way I work is I have in my configuration a set of packages that I want to always have access to. Things like git, vim, gpg and so on.
Then for every dev project I have shell.nix defined which lists project's dependencies. I also have direnv installed, so when I enter that directory, the project's tools are automatically available for me. I rarely change the main configuration and more often project's shell.nix. And for one-off's I use nix-shell -p <package>
But I don't want it temporarily, I want it all the time. So I want to be able to make it available for future me too, that way next time I try to use it I don't have to run `nix-shell -p <package>` again
It will still be on your system until garbage collected, so if you decide to install permanently, it will be instantaneous. "Permanent" is a fuzzy concept with Nix in any case, as all it means here is that it's in your path and won't be garbage collected. In this case you just add the package name to an array in your config. It's extremely simple to do, just editing a list in a text file. I understand you want to just run a command, but perhaps Nix is not for you if easy command line usage is more important than automated reproduceable OS config.
That being said, I think there are indeed ways to partially manage your config using simple command line commands but I haven't found the need myself.
Then I would look into home-manager and/or nix-darwin if you are on macOS.
I think under the hood home-manager basically declaratively manages a Nix profile for you. You (or even better a home-manager managed .bash_profile) can then put that profile into your PATH.
I'm much newer user and admittedly the documentation is not great, so I've used forums and IRC a lot and from what I've gathered, the movement is towards declarative reproduceability. This is the reason for the development of flakes. I saw installation of packages using nix-env in many search results and tutorial pages but newer comments seem to indicate that this is no longer recommended, and it fully makes sense to me. I want to get my machine back to the same state using my config checked into git, and installing imperatively using nix-env clearly goes against this.
