| 16 Oct 2021 |
 colemickens 🏳️🌈 | nix run feels like trying too hard to make flakes some sort of magical docker ux | 23:08:37 |
| colemickens 🏳️🌈 | like I get it, but it doesn't make any sense for a nix repo like nixpkgs, what're ya gonna do, make a flakes.apps.X entry for every bin/app in nixpkgs? | 23:09:00 |
 Dee | legacyApps | 23:09:53 |
| Dee | (I kid) | 23:09:57 |
| 17 Oct 2021 |
 tomberek | I’ve been thinking of adding a “—command” to ‘nix run’ for exactly this reason. | 03:10:41 |
| tomberek | It helps unify the various run/shell/develop sub commands. | 03:11:06 |
|  alice joined the room. | 07:12:41 |
 balsoft | In reply to @colemickens:matrix.org
like I get it, but it doesn't make any sense for a nix repo like nixpkgs, what're ya gonna do, make a flakes.apps.X entry for every bin/app in nixpkgs? No, it falls back to bin/${pname} for binary name by default, so e.g. nix run nixpkgs#hello works | 07:31:54 |
| balsoft | I agree tha it's not very useful :/ | 07:32:04 |
 Roos | I personally disagree, I don't see it as a docker replacement, but rather as a flatpak alternative. | 07:49:21 |
| Roos | IMHO, I don't think we need an entry for all of the binaries, just the 'main' binary of the package (where it makes sense). For instance, if I want to "run" package redshift-wlr, I would like it to run the redshift binary inside, if I wanted to access to any of the other binaries, I'd enter a shell. | 07:52:34 |
| balsoft | In reply to @roosemberth:orbstheorem.ch
IMHO, I don't think we need an entry for all of the binaries, just the 'main' binary of the package (where it makes sense). For instance, if I want to "run" package redshift-wlr, I would like it to run the redshift binary inside, if I wanted to access to any of the other binaries, I'd enter a shell. That's still a lot of app entries | 07:53:32 |
| Roos | Yes, but I don't think that's a flakes problem, I think that's a nixpkgs problem. | 07:53:59 |
| colemickens 🏳️🌈 | Doesn't nix shell pull the pkgs deps in too though? | 08:44:26 |
| colemickens 🏳️🌈 | isn't that like the whole issue | 08:44:40 |
| colemickens 🏳️🌈 | * isn't that like the whole issue - why people try to use run and then wind up resorting to nix shell -c... | 08:45:08 |
| Dee | There's already meta.mainProgram that you can use in Nixpkgs, and Nix actually checks that | 09:10:21 |
| tomberek | The new ‘nix shell’ does not pull in build deps. | 15:43:19 |
 figsoda | From my understanding, nix-shell becomes nix develop, nix-shell -p becomes nix shell, and nix run a special case for nix shell -c | 17:30:50 |
| figsoda | * From my understanding, nix-shell becomes nix develop, nix-shell -p becomes nix shell, and nix run is a special case for nix shell -c | 17:32:03 |
|  mars joined the room. | 19:02:55 |
| tomberek | figsoda: roughly yes, but there are lots of edge cases and slight differences. Getting that design right and making decisions have been difficult. | 20:23:48 |
| colemickens 🏳️🌈 | David Arnold (blaggacao): did you figure out a way to expose/use multiple devShells from a flake? | 23:48:34 |
| colemickens 🏳️🌈 | I guess this works: nix develop .#devShell2.x86_64-linux | 23:49:38 |
| colemickens 🏳️🌈 | kind of annoying that it doesn't get autocoerced from .#devShell2 in that scenario thoug | 23:49:50 |
 David Arnold (blaggacao) | I think there now is self.devShells so I guess, nix develop python should do self.devShells....python | 23:50:05 |
| David Arnold (blaggacao) | Not tested, just a bookmark in my head. | 23:50:55 |
| colemickens 🏳️🌈 | okay, I'll add a note to try that | 23:51:19 |
| David Arnold (blaggacao) | Tell me if it works 🙂 | 23:51:19 |
| 18 Oct 2021 |
| colemickens 🏳️🌈 | David Arnold (blaggacao): aight, it's outputs.devShell + outputs.devShells.foo | 00:15:17 |
