| 13 Oct 2021 |
 Las | It will still work with other VCSes but not as well. | 20:37:30 |
| 16 Oct 2021 |
 colemickens 🏳️🌈 | dude, please tell me I'm confused. | 23:00:58 |
| colemickens 🏳️🌈 | is nix run ... -c command really not a thing anyore" | 23:01:07 |
| colemickens 🏳️🌈 | * is nix run ... -c command really not a thing anymore? | 23:01:10 |
 Dee | I think it's always been nix shell … -c command | 23:06:37 |
| colemickens 🏳️🌈 | -_- | 23:07:13 |
| Dee | yeah, it's kind of... unintuitive | 23:07:37 |
| Dee | since nix run nixpkgs#hello is just pretty much nix shell nixpkgs#hello -c hello | 23:07:59 |
| 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 |
