<{^_^}>
nix#2423 (by ElvishJerricco, 9 weeks ago, open): nix build: Print result paths to stdout with --no-link
<infinisil>
Nice
<infinisil>
Oh and the CLI...
<infinisil>
nix-env should just be discarded
<infinisil>
It's horrible in so many ways
<elvishjerricco>
Haha yea. We need some kind of `nix install` first though.
<infinisil>
I wonder if anybody would have anything against people (e.g. me) implementing `nix install` in Haskell
<elvishjerricco>
Personally I'd love to see home-manager get a command line tool that mutates a JSON file and builds / activates the home-manager config, which would read the JSON file to put packages in `home.packages`
<infinisil>
Well eelco probably, but I sure as hell won't learn C++ just to help with this
<elvishjerricco>
infinisil: The C++ in Nix is shockingly good.
<elvishjerricco>
I hate C++ but working on the Nix codebase is surprisingly pleasant.
<samueldr>
not a C++ fan, worked with it in the past, and I concur, nix has a good codebase
<drakonis_>
consolidate the nixos suite into nix, ty
<samueldr>
no idea what you mean by those words
<infinisil>
Hmm yeah
<infinisil>
But still, I just don't feel comfortable in imperative languages
pie_ has joined #nixos-chat
<drakonis_>
i mean that the commands to manage NixOS could be rolled into nix
<pie_>
hi guys how do i not fail at learning emacs
<drakonis_>
same ^
<elvishjerricco>
infinisil: How would you implement a Nix subcommand in Haskell?
<samueldr>
except nixos is not part of nix
<samueldr>
rolling them up into nix breaks the separation
<infinisil>
elvishjerricco: I think the plugin infrastructure supports custom CLI commands
<pie_>
elvishjerricco: pretty sure profpatsch has done something like that?
<elvishjerricco>
infinisil: The manual claims it does, but it does not
<drakonis_>
who was it that was trying to allow modules outside of nixos?
<elvishjerricco>
infinisil: Adding plugins occurs after command line parsing has completed
<infinisil>
Ahh darn..
<pie_>
ah wait i misunderstood
<elvishjerricco>
drakonis_: The NixOS module system? It's already perfectly usable outside NixOS. home-manager and nix-darwin both use it
<samueldr>
hm, I could take a look again, but I think the change needed for a custom command wouldn't be too onerous to add
<mdash>
pie_: what do you want to learn about emacs
<elvishjerricco>
samueldr: Parsing some command line args first is a necessity since --plugin-files can be specified on the command line
<pie_>
mdash: just...you know....how to use it for programming
<pie_>
or like, at all
<infinisil>
How about `nix <subcommand>` just calling `nix-<subcommand>` if it doesn't have any <subcommand> itself
<samueldr>
elvishjerricco: thankfully, part of the good codebase is the args parsed in nix :)
<samueldr>
infinisil: that approach is good, but a bit impure :/
<infinisil>
samueldr: Could register the binaries in the config too
<elvishjerricco>
Wait really? Like Nix code is executed to parse args? That's neat
<samueldr>
elvishjerricco: no, C++, I meant nix as the project name
<infinisil>
samueldr: Maybe just a `subcommand.<subcommand> = /path/to/binary` in nix.conf
<elvishjerricco>
Ohhh
<samueldr>
infinisil: ah, not a bad idea
<samueldr>
I was about to say: but a good way to try new ideas
<elvishjerricco>
That has a similar problem to args parsing though.
<infinisil>
elvishjerricco: What problem?
<drakonis_>
why is it necessary to separate nix and nixos?
<elvishjerricco>
Args and nix.conf are parsed before doing anything, and parsing a subcommand would require parsing nix.conf first.
<elvishjerricco>
drakonis_: Not all Nix users use NixOS.
<elvishjerricco>
Anyway, I'm struggling to think of any way to make it possible to add sub commands using `nix --plugin-files ...`, short of just having `nix` parse some options itself and setting the config before pass the remainder off to a subcommand, which would then mutate the config
<pie_>
mdash thanks
<pie_>
mdash: i tried some fancy distribution or addon pack for emacs at some point, and that had something for searching for commands
<drakonis_>
spacemacs?
<pie_>
right that
<elvishjerricco>
infinisil: How do you envision `nix install` working? Just like `nix-env` but minus the insanity in the command line interface?
<drakonis_>
why not install to a generation in particular?
<drakonis_>
default to current
<drakonis_>
and removal behaves the same way
<elvishjerricco>
that doesn't make sense. Generations aren't mutable.
<drakonis_>
sorry, i should've expanded, you can create a new generation based on that one
<drakonis_>
ie: create new generation from another then work on it before locking it
<drakonis_>
then that one becomes the current one
<elvishjerricco>
Isn't that basically how it works now?
<drakonis_>
i don't think it is exactly like this
<infinisil>
elvishjerricco: I'd like it to be like emacs customize
<infinisil>
It should do something like the json thing you mentioned
<infinisil>
But with a nix file instead
<elvishjerricco>
Hm. Well, it's very hard to do it in a nix file
<elvishjerricco>
Mutating a turing complete AST sounds hard :P
<infinisil>
The file shouldn't ever be changed by humans though
<elvishjerricco>
But I wanna touch it
<infinisil>
There's a seperate file for you to touch
<infinisil>
Call the generated one ~/.config/nix/pkgs-generated.nix
<infinisil>
Although, Maybe a json would be better
<elvishjerricco>
If humans don't touch it then why shouldn't it be a proper serialization format like JSON?
<infinisil>
I thought i had a reason for it at some point
<infinisil>
Ohh i got it
<elvishjerricco>
infinisil: I wouldn't mind something nixos-rebuild-esque. i.e. You have a file where your manually written things go, and the command just evaluates that with some Nix wrapper that also includes stuff from a JSON file
<infinisil>
elvishjerricco: json files are bad at encoding nix expressions
<infinisil>
And people can install arbitrary expressions
<infinisil>
Not just attr paths
<elvishjerricco>
true
<samueldr>
also, nix-env works on `name` attributes, which is... not the most convenient way to track something :/
<infinisil>
samueldr: let
<colemickens>
love that nix build is just ignoring --builders and building locally anyway and that '-v' gives no extra output
<infinisil>
samueldr: Let's just pretend the name thing never happened
<colemickens>
(and I am a trusted user in /etc/nix/nix.conf)
<elvishjerricco>
colemickens: I think I've used `--builders` with nix build. You sure your user is trusted?
<elvishjerricco>
ah
<elvishjerricco>
infinisil: Maybe just go full nixos-style and say all package management is done by your hand-written nix config?
<infinisil>
elvishjerricco: i really want an imperative command though
<elvishjerricco>
I kinda don't :P
<infinisil>
And i bet if we don't have one, people will write a hacky one themselves
<infinisil>
It's just much easier and faster
<elvishjerricco>
I dunno. You don't see people doing that to NixOS
<colemickens>
oh well, NIX_REMOTE + nix-build works I guess
<infinisil>
elvishjerricco: Yup, that's why I'm sometimes ending up nix-env installing things just because i can't be bothered editing my config and rebuilding..
<elvishjerricco>
Hah fair enough, I've done that
<infinisil>
(Okay that's mostly because rebuilding takes so long.. which is another problem..)
<colemickens>
+1
<elvishjerricco>
But I still don't think we want the state file to be a nix expression. The argument that people want to install arbitrary expressions doesn't work because they don't want those expressions re-evaluated every time they install anything else; they want the same store path as before.
<infinisil>
elvishjerricco: counterpoint: people want to update their packages, which requires reevaluation and different store paths
<elvishjerricco>
infinisil: But if your expression includes a path literal then re-evaluating will surely fail when you change directory
<elvishjerricco>
Next time I `nix install` something, if that exact string is re-evaluated and I'm not in the same directory, it'll break
<infinisil>
Ahh, need to make paths absolute then
<infinisil>
That's a rather simple AST transformation
<infinisil>
Or just disallow relative paths
<elvishjerricco>
infinisil: I prefer the nix-env model of updating; install things with one command and update them with another
<elvishjerricco>
for imperative package management at least
<elvishjerricco>
I shouldn't have to update a dozen unrelated packages to install something new just because I updated my channel
<infinisil>
I mean, updating would still be a separate command in my idea. The generated file just has something like 'import <nixpkgs> {}' at the top, and nixpkgs only changes on updates triggered by the update command (via some json rev/sha256 file)
<colemickens>
then why update the channel if you're not going to update your system?
<infinisil>
Ah
<infinisil>
Yeah ^^
<infinisil>
Okay, but that's a point, we should allow pinning of packages
<infinisil>
This could be done within the generated nix expression
<infinisil>
And add a command 'nix install --pin' or so