| 12 Aug 2021 |
 chreekat | In reply to @mewp:nurupo.pl
stackoverflow says that git update-index --assume-unchanged <filename> should do that Oh, that's cool/weird | 07:22:11 |
 elonsroadster | yeah that is weird | 07:22:26 |
| elonsroadster | it seems like it would be way better to track this in a flat file | 07:22:36 |
| elonsroadster | seems like it could get really confusing if it were accidentally applied or something | 07:22:48 |
| elonsroadster | but anyway that does do basically what I want | 07:23:00 |
| elonsroadster | I still think there are problems, even with this approach, like for example, if you wanted to import from additional flakes in this modification | 07:24:25 |
| elonsroadster | say you wanted to import a flake for the dev tool you want to use | 07:24:56 |
| elonsroadster | there's still not a great way to do that with this approach | 07:25:09 |
| chreekat | It's a slippery slope, though. At what point do you accidentally develop a "works for me" situation if it's too convenient to override things locally | 07:28:02 |
| elonsroadster | bryan: I mean it seems like it could be specifically aimed at nix develop and the devShell attribute | 07:31:06 |
| chreekat | True, the package would still have to pass muster in the build phase | 07:31:49 |
 mewp | nix develop --help says that you can pass a profile to it | 07:32:02 |
| mewp | so you could just have separate profiles per rpeo | 07:32:25 |
| mewp | * so you could just have separate profiles per repo | 07:32:28 |
| elonsroadster | mewp: yeah but I dont think that profile can depend on e.g. the pkgs that was used to define the shell | 07:32:34 |
| elonsroadster | youd have to separately maintain that profile | 07:32:53 |
| mewp | that's true | 07:32:59 |
| elonsroadster | so like with haskell, for example, you use a specific haskellPackages set, and that would be defined by the flake, and you would want to use both the compiler and the haskell-language server version that is used to contruct the shell | 07:33:33 |
| elonsroadster | this could for example change over time, and if you do something thats like nix integrated, you would automatically pick up these changes if upstream for example made changes to the nixpkgs, ghc etc etc. versions they were using | 07:34:10 |
| elonsroadster | Basically I just really want to ultimately AVOID the cognitive load of thinking about like "what compiler version am i using, what nixpkgs am i using".
Thinking about that stuff is just so annoying and such a headache, especially when you are project jumping a lot | 07:35:31 |
 j-k | why cant you create your own flake around the base flake and override rather than modifying the flake but not wanting to commit those modifications? I admit I read through the back and forth here and I don't quite see the usecase here
In the xmonad-contrib you want to import the develop.nix file if it exists but you dont want to commit it right? The whole point of flakes is you only use what you've commited to, what is reproducible, then to try to mutate that immutable environment doesnt work. | 12:15:57 |
| elonsroadster | In reply to @j-k:matrix.org
why cant you create your own flake around the base flake and override rather than modifying the flake but not wanting to commit those modifications? I admit I read through the back and forth here and I don't quite see the usecase here
In the xmonad-contrib you want to import the develop.nix file if it exists but you dont want to commit it right? The whole point of flakes is you only use what you've commited to, what is reproducible, then to try to mutate that immutable environment doesnt work. j-k: Your own flake in the same directory? I mean this is when you're working on developing the code in a repository that contains the flake. If you import the flake as you suggested you run in to two problems:
- Is there even a way to run a flake in a directory if the "flake file" does not have the name flake.nix
- When you import a flake it will generally "lock" the imported flake at a certain revision, this is bad if you are working on the code of that flake because it means you would have to restart the shell with a
nix flake update every time you make a change. Not a nice workflow.
| 18:23:11 |
| j-k | I was just going to say that's the pain of immutability but then I thought about racked but not staged yet files .... so nix flakes lets you run stuff on tracked but not staged yet files and just issues the line warning: Git tree '/home/jk/some/thing' is dirty, this is allowance is probably given as it'd be a PITA to stage every time you want to test a change. Maybe it could allow you to provide a file or dir as an extra dirty file or dir e.g --extra develop.nix and it could warn warning: Extra dirty content provided '/home/jk/some/thing/dirty/develop.nix' ? 🤷♂️ | 18:31:54 |
| j-k | * I was just going to say that's the pain of immutability but then I thought about tracked but not staged yet files .... so nix flakes lets you run stuff on tracked but not staged yet files and just issues the line warning: Git tree '/home/jk/some/thing' is dirty, this is allowance is probably given as it'd be a PITA to stage every time you want to test a change. Maybe it could allow you to provide a file or dir as an extra dirty file or dir e.g --extra develop.nix and it could warn warning: Extra dirty content provided '/home/jk/some/thing/dirty/develop.nix' ? 🤷♂️ | 18:32:07 |
| elonsroadster | In reply to @j-k:matrix.org
I was just going to say that's the pain of immutability but then I thought about tracked but not staged yet files .... so nix flakes lets you run stuff on tracked but not staged yet files and just issues the line warning: Git tree '/home/jk/some/thing' is dirty, this is allowance is probably given as it'd be a PITA to stage every time you want to test a change. Maybe it could allow you to provide a file or dir as an extra dirty file or dir e.g --extra develop.nix and it could warn warning: Extra dirty content provided '/home/jk/some/thing/dirty/develop.nix' ? 🤷♂️ j-k: Right I'm aware of that, but I think you are maybe missing my point. Your idea was to make a separate flake that IMPORTS the original flake, right? | 18:55:17 |
| elonsroadster | In that case, you would still need to nix flake update every time any change is made for it to be reflected, since any imported flake is copied into the store when it is used as a dependency | 18:56:02 |
| j-k | yes that was the idea I posted. you said you didnt like the workflow. I was going to give up but then thought about the dirty behaviour and proposed a potential new feature | 18:56:26 |
| j-k | my 2nd idea has nothing to do with imports or the need to update the flake | 18:56:40 |
| elonsroadster | I see, the seond thing was unrelated | 18:57:13 |
| elonsroadster | Yes actualy reading it now, the second thing is basically exactly what i would want | 18:57:31 |
