| 15 Oct 2021 |
 @timdeh:matrix.org | Lately I've wondering if Nix is actually misclassifying itself as a package manager at all. Perhaps it could more accurately be described as a package compiler. Such a tool is fine for developers who are particular interested in building complex tooling with it, but kinda unsuitable for just quickly installing some packages. | 16:46:00 |
| @timdeh:matrix.org | It might be nice to have a more minimal frontend that works more like a traditional package manager, i.e. it doesn't evaluate anything it just has knowledge of where binaries exist in various caches and knows how to pull them | 16:46:42 |
| @timdeh:matrix.org | but these are just random thoughts floating around in my head, maybe someday I will come up with something more concrete 😅 | 16:49:01 |
 David Arnold (blaggacao) | The appeal of a toml file is familiarity and blocking off too much logic (vs. data) from the entrypoint. | 17:47:30 |
| David Arnold (blaggacao) | I regard nix-lang as a config mgt language with special support for the file system API but no support for remote APIs. | 17:48:29 |
| @timdeh:matrix.org | I think an inputs.nix would actually be really convenient if it were just a list of refs:
[
"github:owner/repo1"
"github:owner/repo2"
github:owner/repo3/someRev"
]
| 17:49:35 |
| @timdeh:matrix.org | * I think an inputs.nix would actually be really convenient if it were just a list of refs:
[
"github:owner/repo1"
"github:owner/repo2"
"github:owner/repo3/someRev"
]
| 17:49:47 |
| @timdeh:matrix.org | toml would be fairly similar but a bit more annoying with all the commas | 17:50:11 |
 @kraftnix:matrix.org | how would you manage naming conflicts if inputs.nix were a list (having multiple versions of nixpkgs)? | 17:51:25 |
| @timdeh:matrix.org | well the way I'd imagine it, you could still have the explicit inputs section in the flake.nix for situations like that | 17:52:12 |
| @timdeh:matrix.org | or maybe even just a ?name= | 17:52:33 |
| @kraftnix:matrix.org | also follows I guess as well, tbh I like having all my input definitions in one place with all the follows defined, it makes it very easy for my to see/manage my immediate dependencies, i would hate the UX of splitting it up (however I guess this would be optional + optimal for the simple flake usecases) | 17:53:56 |
| @timdeh:matrix.org | or maybe the list could just accept an attrs | 17:53:57 |
| @timdeh:matrix.org | I hate having to define follows explicitly though. It's tedious and error prone | 17:54:22 |
| @timdeh:matrix.org | I have a draft issue open for ideas on how we might be able to help with that | 17:54:43 |
| @timdeh:matrix.org | well it's not open yet | 17:54:48 |
| @timdeh:matrix.org | just a file on my harddrive 😛 | 17:55:02 |
| @kraftnix:matrix.org | but how else would you handle follows without follows (this is a bit circular). having the optionality to reduce my closure size my enforcing a follows, with the option of using upstreams is a nice tool imo, i haven't run into too many issues with it (i think) | 17:56:38 |
| @timdeh:matrix.org | anyway, you could probably still do:
[
{ someInput = {}; }
]
if you wanted everything in one place
| 17:57:12 |
| @timdeh:matrix.org | so I'd imagine we could just have some commands that help us a bit | 17:57:25 |
| @timdeh:matrix.org | say a nix flake follow nixpkgs which searches all inputs for a nixpkgs input, and follows the one at the root if found | 17:57:47 |
| @timdeh:matrix.org | it could write to the flake so that it's still declarative | 17:58:01 |
| @timdeh:matrix.org | That covers about 99% of the reason I use follows at least 😅 | 17:59:08 |
| @timdeh:matrix.org | We could even do this a bit more aggressively and/or automatically by simply following any input nixpkgs if there also exists a nixpkgs at the root | 17:59:46 |
| @kraftnix:matrix.org | i think some cli tooling would be nice to auto-setup/configure like that | 18:00:13 |
| @kraftnix:matrix.org | although given how infrequently I add new inputs (and then look at the lockfile to optimise the dependency closure), it's not too much of a bit deal for me | 18:01:13 |
| @kraftnix:matrix.org | having an auto-follow the nixpkgs would definitely be useful though for adding inputs | 18:01:30 |
| @timdeh:matrix.org | yeah it's not really a problem until you are working on an organization full of flakes and trying to remove duplicates on every one 😅 | 18:01:44 |
| @kraftnix:matrix.org | in something a bit more offtopic, has anyone else had a look/play with https://github.com/astro/microvm.nix? | 18:03:29 |
| @kraftnix:matrix.org | i've integrated it (somewhat) into my devos config (although a nice integration requires some changes upstream) and it's pretty neat. i'm trialing it as a replacement for nixos-containers | 18:08:06 |
