| 8 Dec 2023 |
piousdeer | I'm developing a GNOME extension that requires libgsound. These typically have to be patched with GIRepository.append_search_path..bla bla in nixpkgs. Can I do anything on my end to make my extension more Nix-friendly? | 08:05:01 |
piousdeer | I guess I'm going to wrap GSound imports in a try-catch and gracefully disable the features that require it if it fails to import. Still, that doesn't eliminate the need for a nixpkgs patch. Any other suggestions? | 08:07:41 |
| piousdeer set a profile picture. | 08:09:49 |
piegames | No | 08:54:27 |
piegames | I think what would help though if extensions generally exposed their dependencies in the metadata.json | 08:55:16 |
piousdeer | Oh with the new ES Modules system we can do static analysis to detect used dependencies quite easily actually! Plenty of tooling in JS world already does this | 09:27:02 |
piegames | Oh, that would be very interesting if you could integrate that into our automatic packaging | 09:55:12 |
| @adham-omran:matrix.org joined the room. | 10:24:34 |
@adham-omran:matrix.org | In reply to @rpanades:matrix.org I am having a really hard time with the 45 update. In wayland electron apps (slack, mattermost, vscode) do not work anymore for me. And I cannot log in to X 🤣 Can someone let me what is going on with 45 and 23.11? Everything Electron seems to be broken and non-Electron apps too | 10:25:49 |
@adham-omran:matrix.org | I've been having issues and talking for the past week on the Nix/NixOS channel with no real feedback | 10:26:10 |
@adham-omran:matrix.org | There was nothing about this in the release notes or anywhere else | 10:28:00 |
piousdeer | In reply to @piegames:matrix.org Oh, that would be very interesting if you could integrate that into our automatic packaging I'll take a look | 10:30:35 |
vcunat | In reply to @adham-omran:matrix.org There was nothing about this in the release notes or anywhere else Isn't this a repeat of https://github.com/NixOS/nixpkgs/issues/244742 | 14:56:49 |
vcunat | BTW for large upgrades I'd be careful that (1) you reboot and (2) don't use opengl-using apps from very far away nixpkgs version (than your OS). | 14:57:45 |
Jan Tojnar | In reply to @piegames:matrix.org Oh, that would be very interesting if you could integrate that into our automatic packaging btw looks like https://github.com/NixOS/nixpkgs/commit/af9e3ddc1da4c96d35b326d20ba09cedb1a5ac3b still is not sufficient | 20:07:55 |
Jan Tojnar | at this point, I am leaning towards creating wrapper for extension.js that does our typelib manipulation and then uses top-level await of dynamic import to load the actual extension.js file | 20:09:27 |
piegames | In reply to @jtojnar:matrix.org btw looks like https://github.com/NixOS/nixpkgs/commit/af9e3ddc1da4c96d35b326d20ba09cedb1a5ac3b still is not sufficient Why not? | 20:10:07 |
Jan Tojnar | I am guessing the GPasteGtk import here sometimes gets resolved before the body of ./__nix-prepend-search-paths.js is evaluate | 20:11:50 |
Jan Tojnar | I assumed that imports are resolved sequentially and module’s body is evaluated after all static imports in the module are resolved | 20:13:45 |
Jan Tojnar | but it might not be correct | 20:14:03 |
Jan Tojnar | there is loader specification draft but it is not clear to me if it matches the implementations: https://github.com/whatwg/loader | 20:17:16 |
Jan Tojnar | piegames: I am trying the wrapper approach in https://github.com/NixOS/nixpkgs/pull/272995 | 22:29:18 |
piegames | In reply to @jtojnar:matrix.org piegames: I am trying the wrapper approach in https://github.com/NixOS/nixpkgs/pull/272995 Did you try it already? | 22:32:36 |
piegames | Also how well does this approach generealize, so that we may hook this into buildGnomeExtension | 22:32:51 |
Jan Tojnar | yes, it appears to work | 22:33:22 |
piegames | After some reflection, I think that I'd like to package all extensions with buildGnomeExtension, even those not on extensions.gnome.org. This will require some modifications but it should be feasible | 22:33:27 |
Jan Tojnar | I believe it should generally work | 22:34:59 |
Jan Tojnar | it looks like the entry points for extensions are extension.js and prefs.js, which both export default class | 22:36:02 |
Jan Tojnar | * it looks like the entry points for extensions are extension.js and prefs.js, which both default export a class | 22:36:13 |
Jan Tojnar | I guess there could still be some extensions that have not switched to ESM | 22:36:33 |