| 14 Feb 2025 |
 K900 | And every module gets its own inputs | 21:54:12 |
 Charles | (something something path length limits?) | 21:54:15 |
 KFears (no longer human) | I was basically going to have extremely static and rigid TOML thing parsed by Rust and exposing hooks for extensibility in Nix | 21:54:34 |
| K900 | IIRC Node actually just blanket enables long paths on Windows now exactly for this reason lol | 21:54:39 |
| KFears (no longer human) | * I was basically going to have extremely static and rigid TOML thing parsed by Rust and exposing hooks for extensibility in NixLang | 21:54:40 |
| Charles | i think both git and python's installers also do that | 21:54:59 |
| Charles | it's been a loooong time since i've used windows though | 21:55:28 |
| KFears (no longer human) | The reason why I went this route is because the entire fetching in Nix is basically just C++ code with behavior that is kinda bad anyway, and I see "optimistic fetching" as very desirable | 21:55:47 |
| K900 | I do use Windows pretty much daily, but I avoid most of it by just doing all my work on WSL | 21:55:51 |
| K900 | (drm/amd#1417 when) | 21:56:17 |
| Charles | i like how i remember exactly which bug that is | 21:56:41 |
| Charles | optimistic fetching? | 21:56:57 |
| K900 | In reply to@charles:computer.surgery
i like how i remember exactly which bug that is One day I will implant this into everyone's subconscious | 21:58:10 |
| K900 | And eventually the brainworms will reach the HDMI Forum | 21:58:17 |
| KFears (no longer human) | Flakes do optimistic fetching, but it's all one big bad lie and Nix implementations don't provide native optimistic fetching to do this in NixLang, and I heavily dislike FOD-style optimistic fetching | 21:58:25 |
| Charles | good plan | 21:58:46 |
| KFears (no longer human) | In reply to @charles:computer.surgery
optimistic fetching? You specify target branch and fetch HEAD, and only then you write down commit hash to be able to re-fetch this thing again later | 21:59:22 |
| KFears (no longer human) | Basically, the first time you fetch, you have no clue what commit hash you are going to get - hence the "optimistic" part. You fetch, then you write it down | 22:00:08 |
| Charles | also one thing that's tricky about flake inputs is that it performs two jobs:
- fetching the source
- importing the source
in sprinkles (my thing i linked earlier), this is two distinct steps, which are split into the source (for acquiring sources) and input (for doing the import, or performing some other arbitrary conversion before it's used by stuff for generating your output). this split obviates the need for flake = false type stuff
| 22:00:30 |
| Charles | ah gotcha | 22:00:47 |
| K900 | Oh yeah, one of the big things that made me not finish that prototype was porting flakes to it | 22:01:19 |
| Charles | it also means you can override the source without overriding how it's transformed by input, similar to follows in flakes, or you can override the input without overriding the source (no equivalent in flakes), or both | 22:01:47 |
| KFears (no longer human) | FODs are "pessimistic fetches" - you specify exactly what you want to fetch, and only then you fetch. Except that no one does that, and everybody specifies a dummy hash to figure out what hash will be used later, to write it down into the fetcher | 22:02:11 |
| Charles | yeah... it took my several hours to port my dotfiles from flakes to classic nix | 22:02:47 |
| Charles | * yeah... it took me several hours to port my dotfiles from flakes to classic nix | 22:02:51 |
| KFears (no longer human) | So the entire FOD thing has the interface of "pessimistic fetcher" and practical user story of "optimistic fetcher", which is why I dislike it very much | 22:02:57 |
| KFears (no longer human) | My very optimistic and far-reaching dream is to have actual "optimistic fetchers" available in NixLang | 22:03:53 |
 raitobezarius | @samrose:matrix.org: I can just +1 what most folks said, if you need more detailed discussion about your company needs and how Lix may fit, feel free to shoot an email and we can tell you what we honestly see
As a general rule, this is a community project run mostly by volunteers but also some folks here are working for companies (or clients) that make direct use of Nix and sometimes the Lix implementation directly, things may take a bit of time to get right and we won't rush features for the sake of a quick fix, we value correctness and we are not cornered by extract-value premium tooling funded by VC companies in our teams (if that happened, our CoI policy would tell you this fact). At least, this is my 2 cents on "should I use Lix for my company? Is it a non meme implementation of Nix?" | 22:16:37 |
 samrose | raitobezarius: cool I think it makes sense, and is a good policy to do what is right for the project no matter who is using it, nor how much money they have, etc. Maybe there are some companies who would reject that. But there are others that would not. Also some of the people talking to me are just people and not companies, etc. fwiw personally I hope Lix continues to be this way, and continues to succeed and grow without changing this aspect. I think the kinds of questions I was asking are good, and that it can be useful to answer them. But lix as a mostly volunteer open source project doesn't owe anyone any answers to these questions, nor does it owe guarantees or any other outcome other than what you all decide together to commit to, whatever that may be. Never the less I appreciate the answers that people offered here. And I'll be sure to include that there is an intention to like what you describe above. I feel that is important for people to understand if they want to use, contribute, etc so I will pass that aspect along as well | 22:23:49 |
| samrose | I appreciate the https://lix.systems/team/ conflict of interest statements too. Sets a better example, and this problem grew out of control in some ways in the Nix community. People who were trying to lead should have been doing that. | 22:28:12 |
