| 12 Oct 2021 |
 Pacman99 | I think this post sort of summarizes the problems with fups patching system and why I would be wary of integrating it into digga: https://github.com/gytis-ivaskevicius/flake-utils-plus/pull/90 | 20:01:17 |
| Pacman99 | Its a really cool feature, but it is setup in a rather messy way | 20:02:03 |
 @kraftnix:matrix.org | got it, good to know, guess i'll cross my fingers for a resolution at the nix level. in the meantime, anyone have a good workflow for maintaining a fair number of patches to nixpkgs and keeping it up to date? | 20:07:02 |
 @timdeh:matrix.org | a simple derivation that only runs the patch phase should do it | 20:08:00 |
| @timdeh:matrix.org | (along with a list of desired patches) | 20:08:14 |
| 14 Oct 2021 |
| Pacman99 | So I think I added bors to divnix/bud, but we need to fix the checks for that to be of any use | 17:25:00 |
| 15 Oct 2021 |
 @gytis-ivaskevicius:matrix.org | hey guys, at some point there was some conversation on flake inputs in toml file | 11:48:59 |
| @gytis-ivaskevicius:matrix.org | i'd like to note long forgotten ini format - it allows using pretty much any characters in its sections | 11:49:33 |
| @gytis-ivaskevicius:matrix.org | 
Download image.png | 11:49:36 |
| @gytis-ivaskevicius:matrix.org | may come in handy | 11:49:49 |
| Pacman99 | INIs main problem is that there is a lack of a standard spec. TOML has exactly one spec that is universal and well maintained. | 16:01:42 |
| @timdeh:matrix.org | Nix does have it's own ini like format for the nix.conf already, so I guess we could use that | 16:03:13 |
 ultranix | i didnt understand the desire to move away from a nix-based flake config file, what's wrong with nix | 16:32:29 |
| @timdeh:matrix.org | I dunno, I guess people are always looking for a reason to not use Nix, of which unfortunately there are plenty... | 16:38:27 |
| @timdeh:matrix.org | It's difficult to install on some systems (darwin), Nix the language has strange syntax and may be unfamiliar especially to users who have never worked in a purely functional language, nix evals can take an infinite amount of time, etc | 16:39:21 |
| @timdeh:matrix.org | working professionally with a bunch of Mac OSX users who range from semi to very hostile to Nix, I've become more aware of these issues lately | 16:41:56 |
| @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 |
