20 Oct 2024 |
emily | I would like to write a general-purpose Nix refactoring framework | 04:48:34 |
emily | I do not think anything exists currently that can reliably achieve the kind of thing you are going for | 04:48:45 |
emily | but I would like one to exist | 04:49:11 |
emily | my understanding is that most uses of Qt 5 in Nixpkgs might not have that long to live anyway though. you may wish to coordinate with K900 | 04:49:42 |
Tomodachi94 | I have an idea that involves basically chaining a bunch of sed invocations and also accounts for the preexisting formatting at the same time (shudder), but that falls apart when I need to insert something | 04:50:51 |
Tomodachi94 | I had an idea that involves basically chaining a bunch of sed invocations and also accounts for the preexisting formatting at the same time (shudder), but that falls apart when I need to insert something | 04:50:58 |
Tomodachi94 | In reply to@emilazy:matrix.org my understanding is that most uses of Qt 5 in Nixpkgs might not have that long to live anyway though. you may wish to coordinate with K900 See also, the tracking issue for this: https://github.com/NixOS/nixpkgs/issues/180841 | 04:52:20 |
emily | In reply to @tomodachi94:matrix.org I had an idea that involves basically chaining a bunch of sed invocations and also accounts for the preexisting formatting at the same time (shudder), but that falls apart when I need to insert something if you can rely on nixfmt then you can do horrible things like replace nativeBuildInputs = [ | 04:52:55 |
emily | but yes, not being able to think of a good way to do a build inputs-affecting refactor for macOS stuff is why I started planning a proper framework | 04:53:20 |
Tomodachi94 | In reply to@emilazy:matrix.org if you can rely on nixfmt then you can do horrible things like replace nativeBuildInputs = [ Yep, Another tricky thing that nixfmt might have fixed would be removing the "import" of qt5.mkDerivation when it uses qt5.callPackage (the format is wildly inconsistent) | 04:54:27 |
Tomodachi94 | I had an idea that involves basically chaining a bunch of sed invocations that also account for the preexisting formatting at the same time (shudder), but that falls apart when I need to insert something | 04:54:48 |
emily | I think it would be okay to nixfmt files before touching them | 04:54:59 |
emily | going by ripgrep results, we're talking about some ~40 packages? | 04:56:06 |
emily | I think you're best off just doing it manually | 04:56:10 |
Tomodachi94 | I do have a script that lists most of the problematic files (afaik) | 04:56:11 |
Tomodachi94 | In reply to@emilazy:matrix.org going by ripgrep results, we're talking about some ~40 packages? Closer to 600, qt5.callPackage obscures them | 04:56:28 |
emily | i was grepping for qt5.callPackage , i guess i did it wrong | 04:56:39 |
Tomodachi94 | In reply to@emilazy:matrix.org i was grepping for qt5.callPackage , i guess i did it wrong I also did something similar initially 🙈 https://github.com/NixOS/nixpkgs/issues/180841#issuecomment-2423659515 | 04:57:36 |
emily | oh, because libsForQt5 . | 04:57:53 |
emily | I believe that the Plasma 5 parts of those will go away at some point according to K900's intention | 04:58:15 |
emily | so you could perhaps ignore pkgs/applications/kde | 04:58:29 |
Tomodachi94 | In reply to@emilazy:matrix.org oh, because libsForQt5 . Didn't even think about qt5.mkDerivation too, completely missed that | 04:58:51 |
Tomodachi94 | (I did a treewide that fixed most of the libsForQt5-prefixed invocations, except one that I accidentally skipped) | 04:59:35 |
Tomodachi94 | * (I manually did a treewide that fixed most of the libsForQt5-prefixed invocations, except one that I accidentally skipped) | 04:59:41 |
emily | yeah. sadly the best options are manual work or writing a hacky bespoke tool right now. that may change soon depending on how macOS stuff goes | 05:01:42 |
emily | you could coordinate something like https://github.com/NixOS/nixpkgs/issues/326513 if you have a good list of affected packages, but for Qt 5 a lot of them probably won't be around forever (e.g. K900 wants to get rid of Plasma 5, we'll probably have to drop qtwebengine once upstream stops supporting it, etc.), so I would try to ensure you don't waste effort on stuff that will be removed | 05:02:57 |
mj | so I'm looking to maintain/introduce a package to NixOS which has multiple output binaries. Is it still best practice to write it into pkgs/by-name/* ? | 05:11:17 |
mj | * so I'm looking to maintain/introduce a package to Nix which has multiple output binaries. Is it still best practice to write it into pkgs/by-name/* ? | 05:11:33 |
mj | * so I'm looking to maintain/introduce a package to nixpkgs which has multiple output binaries. Is it still best practice to write it into pkgs/by-name/* ? | 05:11:43 |
mj | it's a platform | 05:12:54 |