| 8 Dec 2023 |
 @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 |
| piegames | Isn't it required at least for all Gnome 45+ extensions? | 22:37:54 |
| Jan Tojnar | and I guess some extensions could export some other symbols in the entry point and then cyclically import the entry point from other module | 22:38:03 |
| Jan Tojnar | but that would be extreme yuck | 22:38:12 |
| piegames | We could make a flag for that. Or wait one more cycle and then throw out everything <45 | 22:38:14 |
| Jan Tojnar | I though so but I still saw the legacy imports in the official extensions | 22:39:15 |
| Jan Tojnar | never mind, I misremembered, it was GNOME Shell itself, and it is ESM, it just uses the old import style as well https://github.com/NixOS/nixpkgs/blob/a87dd3d3d9ea483ccddc51ffc300ef0f336e2b96/pkgs/desktops/gnome/core/gnome-shell/wrap-services.patch#L16 | 22:41:53 |
| Jan Tojnar | In reply to @piegames:matrix.org
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 How would that even work when an extension requires building? Does not buildGnomeExtension just unpack a tarball? | 22:44:57 |
| Jan Tojnar | In reply to @piegames:matrix.org
Also how well does this approach generealize, so that we may hook this into buildGnomeExtension in the longer term, I would probably want to make gjs support specifying the typelib path as part of the import statement | 22:46:54 |
| Jan Tojnar | similarly how it allows setting version | 22:47:09 |
| piegames | In reply to @jtojnar:matrix.org
How would that even work when an extension requires building? Does not buildGnomeExtension just unpack a tarball? You build a tarball as would be uploaded to extensions.gnome.org and then pass it as source to buildGnomeExtension. It then takes care for you of putting everything into place and fixing the dependencies and stuff. The idea is that we can then have patches etc. in extension-overrides.nix, which means less copying stuff around when extensions switch between manually packaged or not (e.g. due to early support for the next Gnome version) | 22:47:32 |
