| 3 Oct 2024 |
 autra | maybe we want to ship postgis 3.5 before the "no breaking change" | 07:43:54 |
| autra | window though | 07:43:56 |
 Ivan Mincik (imincik) | In reply to @autra:trancart.eu
Hi! do we have blockers for 24.11? (I didn't see any but...) I just wanted to report that we don't have any blockers, but I agree that we should try to get postgis 3.5 to 24.11. | 11:45:08 |
| autra | ok pushing my wip now :-) | 11:59:37 |
| autra | As soon as we think we are ready, we should check the box here: https://github.com/NixOS/nixpkgs/issues/344920 | 13:15:39 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
As soon as we think we are ready, we should check the box here: https://github.com/NixOS/nixpkgs/issues/344920 Yes. | 14:48:30 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
ok pushing my wip now :-) PR looks good. Can I merge now ? | 14:50:44 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
ok pushing my wip now :-) * autra: PR looks good. Can I merge now ? | 14:50:55 |
| Ivan Mincik (imincik) | I think, we should also try to merge
https://github.com/NixOS/nixpkgs/pull/342101
and
https://github.com/NixOS/nixpkgs/pull/344664
| 14:57:21 |
| autra | In reply to @imincik:matrix.org
autra: PR looks good. Can I merge now ? I wanted to take the opportunity to add two little tests in nixos/tests | 15:35:18 |
| 4 Oct 2024 |
| autra | Ivan Mincik (imincik): btw, about the "QGIS: don't build with GRASS by default" issue in the board, what's the rational? (I use it from time to time and I'll be moderately in favor of keeping it by default for the discoverability in the processing pane) | 06:58:23 |
| autra | that being said, a withGrass makes sense. | 07:35:47 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
Ivan Mincik (imincik): btw, about the "QGIS: don't build with GRASS by default" issue in the board, what's the rational? (I use it from time to time and I'll be moderately in favor of keeping it by default for the discoverability in the processing pane) To make a QGIS closure small by default | 08:28:03 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
that being said, a withGrass makes sense. Yes, but we really need to come with a better way of unwrapped package overriding . | 08:28:53 |
| autra | In reply to @imincik:matrix.org
Yes, but we really need to come with a better way of unwrapped package overriding . at the same time, I'd say we can start simple and see after. If we have only 5-10 parameters, just propagating them to the callPackage ./unwrapped {} thing is really ok imo. | 09:21:56 |
| autra | or maybe I'm missing your point though. | 09:22:16 |
| autra | I'm not against a bit of boilerplate if it makes things simpler to write and easier to read. | 09:22:34 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
at the same time, I'd say we can start simple and see after. If we have only 5-10 parameters, just propagating them to the callPackage ./unwrapped {} thing is really ok imo. The problem is unwrapped package being called via let binding which makes very hard to use parameters from unwrapped package. We need to come with something better to make it more user friendly. | 09:25:19 |
| Ivan Mincik (imincik) | Do you have some ideas ?
| 09:25:28 |
| autra | we can just propagate it like that: https://github.com/NixOS/nixpkgs/compare/master...autra:nixpkgs:qgis_unwrapped_param
That'll work, right? | 09:28:56 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
we can just propagate it like that: https://github.com/NixOS/nixpkgs/compare/master...autra:nixpkgs:qgis_unwrapped_param
That'll work, right? Yes, this works and I am not personally against this approach. | 09:30:24 |
| autra | a bit of boilerplate.... but simple and straight to the point. | 09:30:36 |
| Ivan Mincik (imincik) | If nobody comes with a better idea I am OK with that. | 09:31:05 |
| autra | for me, that works best for things that are actually set at compile time (like grass, if I understand correctly), also because the number of possibilities is limited | 09:31:51 |
| autra | this doesn't really work for plugins that needs a native counter-part, like saga | 09:32:08 |
| autra | in this case, I'd maybe go for a qgisPackages.saga, which would draw the saga deps and the plugin, like we have postgresqlPackages, pythonPackages... | 09:32:46 |
| autra | maybe a bit more involved for us maintainer :-) | 09:33:03 |
| autra | but it opens up more possibility. | 09:33:18 |
| autra | (again, if I understand things correctly about this construction) | 09:33:31 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
in this case, I'd maybe go for a qgisPackages.saga, which would draw the saga deps and the plugin, like we have postgresqlPackages, pythonPackages... I like this idea. | 09:33:37 |
