 | Nix Flakes | 859 Members |
| 177 Servers |
| Nix Flakes | 859 Members |
| 177 Servers |
| Sender | Message | Time |
|---|---|---|
| 7 Mar 2025 | ||
 Adam Neverwas | And i wanna know, what would be the best place and mode to install android studio? | 16:59:11 |
 puffnfresh joined the room. | 22:17:31 | |
 elikoga | How is this related to flakes | 23:02:22 |
| elikoga | https://discourse.nixos.org/t/determinate-nix-3-0/61202/92?u=elikoga | 23:02:39 |
 @illegitimate-egg:matrix.org left the room. | 23:04:11 | |
| 8 Mar 2025 | ||
 nf changed their profile picture. | 10:43:20 | |
 Gregory Malecha joined the room. | 20:42:15 | |
 Qyriad changed their display name from qyriad to Qyriad. | 21:41:03 | |
| 9 Mar 2025 | ||
 osbm | Hello, elikoga
I am trying to understand your point. What exactly is wrong with this? I started using nix in the last year and since every body is recommending it i started using flakes. It feels better to use a generalized entypoint to all your code, instead of /etc/nixos/configuration.nix, shell.nix, default.nix, and channels. And all my nix related projects always use flakes. I dont think i am harming anybody. Do you think that too many new users became too dependent on an experimental feature too fast so that the maintainers cant destructively improve upon the flakes design without facing backlash? | 13:26:21 |
| elikoga | People refuse to stabilize flakes because agitators shit and piss themselves about minor design decisions Flakes cli gets distributed in the nix cli (good) But remains gated behind a flag (bad) And since it's not part of nix main the communication around this feature gets incredibly confusing. I believe that the v1.0 semantics of flakes are obviously finished and all the arguments I can see going against this are bad-faith, non-users, agitators, that deliberately misrepresent the technical state | 13:29:45 |
| osbm changed their display name from osman bayram to osbm. | 13:30:38 | |
| elikoga | Nothing wrong with nix flakes channel being "nix-programming-general" (except for off/on-topic) it's just that agitators don't seem to acknowledge that fact | 13:32:04 |
| osbm | Is there a roadmap/backlog for a feature to stop being an experimental feature? Or are just the discussions stopping this? | 13:34:49 |
| elikoga | In reply to @osmanfbayram:matrix.org Oh of course: https://github.com/NixOS/nix/milestone/27 But: "As of yet, we are largely dependent on contributions, so this milestone does not have a due date, or any timeline." | 13:36:27 |
| elikoga | I'd also love to be able to use this channel to discuss stuff like this but it's filled with "nix-programming-general" because lockfile management is one of the features that gates a lot of nix usage | 13:39:40 |
 @ma27:nicht-so.sexy | In reply to @elikoga:matrix.orgso first of all, I strongly disagree that the current issues (flakes being unusable in a monorepo - I still use the old CLI when hacking on nixpkgs; 1000 instances of nixpkgs problem which makes writing flakes with a larger number of inputs pretty painful for me - just to name the two most important issues I have) are actually minor. the milestone tells me the former thing is somethign the cppnix maintainers also agree. so labelling people as bad-faith agitators if they don't want to stabilize flakes in their current form sounds a bit like an oversimplification tbh. | 14:03:56 |
| elikoga | I'm playing a little bit of devils advocate so let me continue: The milestone stuff was done following https://github.com/NixOS/rfcs/pull/136 which explicitly outlines as one of it's goals "soothe longstanding tensions" As it stands, "flakes being unusable in a monorepo" is a phenomenon where the first-order implementation of pure evaluation in flakes (copy source to store) fails to scale properly. I'd love to see more work wrt any workarounds for this (lazy paths) or something like that but I don't care, just use the old interface, which I'm not advocating for depreciation or ripping out. When it comes to 1000 instances of nixpkgs problem this again reminds me of for example "peerdependencies" of npm. As we can see in the docs: https://docs.npmjs.com/cli/v11/configuring-npm/package-json#peerdependencies , the feature has experienced semantic changes from v2 -> v3 and also from v6 -> v7 to arrive at current day behaviour of npm. I am sure that such iterations are also possible for the nix ecosystem, if only there was any v1 to work with. | 14:44:04 |
| elikoga | * I'm playing a little bit of devils advocate so let me continue: The milestone stuff was done following https://github.com/NixOS/rfcs/pull/136 which explicitly outlines as one of it's goals "soothe longstanding tensions" As it stands, "flakes being unusable in a monorepo" is a phenomenon where the first-order implementation of pure evaluation in flakes (copy source to store) fails to scale properly. I'd love to see more work wrt any workarounds for this (lazy paths) or something like that but I don't care, just use the old interface, which I'm not advocating for deprecation or ripping out. When it comes to 1000 instances of nixpkgs problem this again reminds me of for example "peerdependencies" of npm. As we can see in the docs: https://docs.npmjs.com/cli/v11/configuring-npm/package-json#peerdependencies , the feature has experienced semantic changes from v2 -> v3 and also from v6 -> v7 to arrive at current day behaviour of npm. I am sure that such iterations are also possible for the nix ecosystem, if only there was any v1 to work with. | 14:44:42 |
| elikoga | Btw there is no v1 of flakes | 14:44:59 |
| elikoga | Except of course for the release scheme of github:nixos/nix , which is refered to when experiencing incompatibilities from flakes relases. See this example in the wild: https://github.com/nix-community/fenix/issues/129#issuecomment-1841700283 | 14:48:56 |
 emily | is your proposal to remove the experimental flag but be willing to make breaking changes, or to have eternal backwards compatibility layers for old versions? | 14:51:16 |
| elikoga | Pragmatically, whenever appropriate both. There should be a v1 and if we are so inclined a v2 in 10 years or less. | 14:53:23 |
| elikoga | But if you want to add to add the attribute "lastModified" to tarball inputs then it's a breaking change for some and you should add backwards compatibility since It's not deserving of being a format-bump Just as has already happened in github:nixos/nix as far as I can see | 14:54:57 |
| emily | ok. I think you underestimate the burden and headaches of supporting e.g. the exact current weird/busted fetchTree semantics for all of eternity (indeed there have been recent bugs where the fixes would have been considered potentially unacceptable compatibility breaks for stable Nix already iirc). flakes are not nearly as simple under the hood as they appear on the surface | 14:55:50 |
| elikoga | Links would be lovely | 14:56:30 |
| emily | I don't think it's a conspiracy that almost everyone who works on a Nix-derived codebase thinks that stabilizing flakes is a very complicated process | 14:56:35 |
| emily | and I do use flakes. but anyway, you can consider me an agitator deliberately misrepresenting the technical state if you wish | 14:57:03 |
| emily | https://github.com/nix-community/fetchTree-spec didn't get off the ground yet but involved people from three separate Nix implementations and there's some documentation of very weird behaviour in the issue tracker. most of this stuff is just scattered across a dozen issue reports and PRs though. | 14:59:58 |
| emily | also roberth already gave a good example: | 15:00:17 |
| emily | "As a brief example, we’ve had a case recently where users were using flake inputs to fetch submodules. This is completely unnecessary since 2.26, and it only worked for them because their working directory happened to coincide with the flake root. Sensitivity to the working directory instead of base directory is bug, so here you see an interaction between the two kinds of stability that we discussed. If we had committed to the 2.25 behavior of flakes by blessing it as stable, we would have to implement a completely unnecessary feature which would even require some architectural changes, removing the separation between fetchTree and the base directory concept, forever making call-flake.nix and the native code that interacts with it more complicated." | 15:00:25 |