Open CAM-Gerlach opened 6 years ago
Thanks for your comments: these are all good ideas, unfortunately it is manpower that lacks here.
For the time being: http://plugins.qgis.org/plugins/plugins.xml?qgis=3
Thanks for letting me know. I retitled my second section to include "workarounds", which already included the above as well as doing the same from the QGIS plugins manager.
The very first one should be easy, at least. It would seem that just modifying plugins/templates/plugins/plugin_detail.html by inserting
<th>{% trans "Maximum QGIS version" %}</th>
after line 181
and
<td>{{ version.max_qg_version }}</td>
after line 195 should do the trick. However, the time needed to setup up Docker, Python, Django etc just to test this small and straightforward change seems rather prohibitive. If I submit a PR, will I have a way of testing/previewing it otherwise? Is there a dev/testing/staging version of the site somewhere?
Sorry: no staging, no continuous integration, no continuous deployment :(
Please note that this project was one many years ago by volunteers (and some of those volunteers are now too busy fixing QGIS C++ core).
Your help would be really appreciated, if I can help you in setting up a dev env (and document the process along the way) please let me know.
btw, I don't think you absolutely need a docker (well maybe for the ancient postgis needed here), a virtualenv might be sufficient.
Aww; it did seem a little rough around the edges but I had no idea the whole system was that old! Python 2.5, geez...I was in elementary school back when that was released, and with my young age and being an atmospheric science grad student I've hardly even used Python 2 at all except for a bit with ArcGIS, QGIS and a few scripts; everything else I do in my "day job" as a GRA (research, machine learning, data analysis, library development, etc) is all Python 3, and on the Spyder IDE dev team we've all used Python 3 for a long time and only support as low as 2.7.
Anyway, so I'm willing to give it a shot, though how much help I'll actually be is uncertain since I have only very rudimentary experience with web-related stuff, and am a member of the Spyder core dev team and have a number of different commitments there (issue tracker, bug fixes, grant/doc/blog/etc. writer/editor, doc repo maintainer, help with the website, etc). I am currently on Windows unfortunately due to some of the software needed for my research (though I'll be building a new Linux workstation as soon as I can get some funding).
So, I installed VirtualBox, and used that to install and get Fedora 28 with LXQt up and running so I'd have a proper linux dev environment for this. However, after all that I promptly realized I was a n00b when I looked at the readme here, and realized it was based on a Debian-like distro instead...oh well. Anyway, I couldn't find any of the packages in the first step in the normal Fedora package repos.
So...should I just need to find the right repo/package names? Install Lubuntu or Debian instead? Or do something else? Sorry, most of what I do is pretty much the opposite end of the spectrum from DevOps-type stuff so you're dealing with a rank n00b here.
Summary Description
Given that QGIS 3 both has a raft of breaking changes in its APIs, and upgrades to Python 3 from Python 2, all but the most trivial plugins need to be updated. Therefore, it seems clear there would be a need for users to quickly and easily tell whether a given plugin supports QGIS 3, and filter searches by QGIS (maximum) version compatibility.
Current Situation and Workarounds
With regard to the current situation, apparently the only way to determine a plugin's QGIS 3 compatibility (i.e. its max supported version) is to
Versions
tabMaximum QGIS version
item near the bottom of the list of attributesEven though I was specifically looking for it, I actually didn't find it myself at first and only on the second attempt figured it out.
When browsing plugins from within QGIS it filters by your version automatically, but particularly when evaluating whether and when to move to QGIS 3 and the current state of the ecosystem, it would be rather beneficial to have the web app actually be useful and be able to view the richer and more informative web UI while still filtering by or easily determining version compatibility, and not have to fire up QGIS and know to manually change the version string sent to the server to see what's available for a different version (which many average users may not know or think to do).
Furthermore, the only way to filter plugins by QGIS version on the site is to know to manually pass
qgis=3.0
tohttps://plugins.qgis.org/plugins/plugins.xml
(i.e. what the QGIS plugin manager uses), and even then the appearance and UI is something out of the 90s, complete with the long out of date page titleQuantum GIS Python Plugins
, and the only way to navigate it is with your browser'sFind
on page feature.Suggested Changes/Improvements
Therefore, the following changes, from simplest but most limited to more impactful to more involved, would address this issue:
At absolute minimum, that I presume should be very straightforward for someone to implement (I'm familiar with Python, but have no experience with Django myself) is to add a
maximum version
column to the table on the Versions page, as that is generally more relevant to the user than the minimum version that is displayed at least for the time being, and plenty of room exists even on a non-hidpi monitor.Probably not much more complicated would be adding either sortable columns All Plugins browse table, either for the max (and min) QGIS version, or with boolean value indicating QGIS 2 and QGIS 3 compatibility, as pulled from the latest non-experimental, non-deprecated version available for each platform (and possibly a third value indicating an experimental or deprecated version is available).
Given search results are presently displayed as a (rather awfully bare) list of titles with no metadata like in the All Plugins table, and would require clikcing through to view the version, it would be nice to have a a simple visual "tag" or "badge" visible on the plugin detail page (i.e. above the tab content, such as to the right of the plugin name), and even better to the right of the name in the search results, signifying that at least one non-experimental version is QGIS 3 compatible; I'm thinking a look along the lines of a Github issue tag next to the issue name, somewhat like this: QGIS 3. Similarly, at some point if not immediately you'd also want a similar one for QGIS 2, if a QGIS 2 compatible version exists (as new plugins are increasingly likely to be QGIS 3 only at some point).
Finally, a way to filter searches by version (and other properties, eventually) would take a bit more effort I imagine, and is more of a "nice to have", but is certainly something that would be desired at some point (along with other filters) to greatly improve the current experience searching the online repo.
Again, I have no direct experience with
Django
; if given sufficient guidance and time to get a dev environment installed and set up, I could try to help with some of the simpler elements of this, but it would probably quickest and most efficient if someone who actually knew what they were doing implemented this. Thanks!