Yea, but I preferably don’t want to have to lookup a website for every plugin if somebody gives me a list of plugins to install.
If you have plugins, there will generally be a few categories: 1) The ones that only use Python 2) The ones that use Python and custom python modules, or native binaries 3) The ones that use Python R/Java/.NET/C/C++/Ruby/Whatever Now 1) goes into all platforms, everything else into a platform repository, because it anyway has to. (JRE in the proper version is not necessarely installed) And done. No metadata necessary. Since the QGIS maintainers know for which platforms they compile QGIS, that limits the list of necessary platform repositories. If a third-party wants to support another platform, they can make their own repo. If it gets traction, it can be added to the main, if not, then it’s good the way it is. Anyway, since there might be native dependencies, the whole thing would belong into apt/yum/pacman/whatever in the first place, because that is where package management happens, and plugin management is exactly that. If I want to update qgis to the latest version, I should at the very least get warnings if plugin X is not ready – and I should get that warning the moment I want to update qgis. Which is why it would belong into the package manager. Von: Matthias Kuhn [mailto:matth...@opengis.ch] Gesendet: Mittwoch, 6. Februar 2019 17:46 An: Stefan Steiger <stei...@cor-management.ch>; C Hamilton <adenacult...@gmail.com> Cc: qgis-dev <qgis-developer@lists.osgeo.org> Betreff: Re: [QGIS-Developer] Windows only version of a QGIS 2.18x plugin Hi On 2/6/19 5:28 PM, Stefan Steiger wrote: The problem with metadata is that if you use it, you have no way to easily know if something (a group of plugins) uses a platform-specific plugin. For example, in ubuntu, I can choose: - Official (secure) - Universe (insecure/half-legal) - Partner (copyrighted/patented) - and of course custom repos So if somebody or some tutorial tells me to add the « universe » repo, I know instantly not to do that on a server or in a security-critical situation. If it instead would tell me to install package x, which then installs 20 other packages, which then each install more packages – how do I even filter that information if I have per-package metadata ? I wouldn’t even use metadata for that, because something might run on Linux, but not on your specific version, for example ARM processor on Linux Chromebook. You’ll have to subdivide by processor for binaries. Plugins can depend on other plugins. It might be even better to have 5 repositories: All-platforms, Windows-only, Linux-Only, Mac-Only, Rest-of-the-world So if your plugin works on Windows and Linux, you just upload it to the 2 repositories, and finished. If somebody then tells me to add a „windows only“ plugin, I know to steer clear of that shit if I use Linux, and vice-versa. And that without having to lookup metadata. I agree that if we want to have plugins sorted by their legality or other somehow dubious practices, separate repositories are a good way to go. Plugins which only support a subset of possible platforms are in no way more nor less critical than any other plugin which claims to support all platforms. The metadata we talk about here is not something to lookup by people on a regular basis, but for - the plugin manager to check if it's suitable for the current platoform (i.e. it will not even offer me to install it on my Linux machine), just like Ubuntu won't even offer arm packages if it's running on a x86_64 machine. - general information purpose on the plugin website Matthias
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
