| 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 |
autra | the only challenge I see, is that we might be tempted to start packaging a lot of plugins then. Exactly like python, which basically "duplicates" part of pypi. I'm not against that, but it might need a bigger workforce I don't know | 09:35:07 |
autra | might be bigger than we can chew | 09:35:31 |
Ivan Mincik (imincik) | It would be really great if we could discuss things like that as a team. For long I am thinking about team video call. Not sure if people would like it. | 09:39:58 |
autra | No problem for me :-) It could help brainstorm, at least. | 09:41:45 |
autra | some oss projects do regular dev meetings, not necessarily limited to team members btw, for instance. | 09:42:20 |