Adopt g-sherman/Qgis-Plugin-Builder
reinvantveer opened this issue · comments
QGIS Enhancement: Adopt g-sherman/Qgis-Plugin-Builder into qgis/Qgis-Plugin-Builder
Date 2021/03/30
Author Rein van 't Veer (@reinvantveer)
Contact rein at geodan dot nl (as though this can't be parsed by scrapers anyway)
maintainer @reinvantveer
Version QGIS 3.X
Summary
Gary Sherman's plugin builder plugin is extremely helpful to bootstrap common QGIS plugin components and get started very quickly with plugin development. However, it looks like development on the repository has ceased (which is not a complaint but just an observation. Everyone's time is limited).
This QEP proposes to adopt the code in the repo into the QGIS repositories in order to share the burden of maintenance, review and release. Opening up more routes for development.
Proposed Solution
Either:
- Transfer ownership of the repo or
- Add maintainers to the project
- Fork the project
Plus:
- Ask @g-sherman or @timlinux if he is willing to grant push rights or credentials to the plugin repo for new releases
Affected Files
https://github.com/g-sherman/Qgis-Plugin-Builder
Further Considerations/Improvements
Some things to refactor on the plugin, all beyond the scope of this QEP:
- Update tests to work with QGIS3
- Use only pb_tool to deploy locally
- Use more commonly used pytest tests, maybe even using the pytest-qt plugin if it proves useful
- List plugin dev dependencies in some kind of commonly used requirements file (requirements.txt/pipenv/poetry or whatever)
- Add CI testing with GitHub Actions (I experimented a little, it's awesome)
Backwards Compatibility
Any QGIS 3 version
Votes
(required)
My 2 cents: I'm not sure I can see a benefit of adding this in QGIS directly as opposed to leaving this as an external plugin. There are plenty of useful plugins, but I don't think everything should go into the core because it is useful, that's the goal of every plugin.
Plugin development is not a thing that most users do or have a need to.
My 2 cents: I'm not sure I can see a benefit of adding this in QGIS directly as opposed to leaving this as an external plugin. There are plenty of useful plugins, but I don't think everything should go into the core because it is useful, that's the goal of every plugin.
Plugin development is not a thing that most users do or have a need to.
Yeah OK that aspect is pretty far out of scope, I agree. I'm updating the QEP to reflect.
Is there any real benefit from this becoming an official qgis project vs a third party one?
I struggle to see past the downside of increasing maintenance cost for the project. If it's an official plugin, the responsibility lies with qgis.org to maintain it, vs leaving as a third party plugin where the burden is shared by the community of qgis users instead.
That said, regardless of whether the plugin is moved or not it's great to hear that you're keen to improve it!
Is there any real benefit from this becoming an official qgis project vs a third party one?
Yes I believe there certainly is. There is a great deal of talk going on regarding restructuring plugin development, such as #202 and #179 (as you're well aware). With the plugin builder, QGIS can help people adopt any new strategy of plugin/plugin dependency management without having to read through a lot of documentation just to get started.
I've skimmed a few github repos where plugins are maintained, and a great many of them make use of the plugin builder.
I've skimmed a few github repos where plugins are maintained, and a great many of them make use of the plugin builder.
True, but a widely used plugin doesn't need to be made official!
There's also the issue that the plugin builder currently uses a lot of practices which are no longer recommended, such as things like resource files. I'd never use this approach for modern plugin development, so I'm uncomfortable with the thought of the plugin builder bring made "official" and seen as the tool for best practice plugin development.
I'd love to see the tool updated and modernised first, before we consider branding it as official...
It would also be worth considering the approach taken by https://github.com/wonder-sk/qgis-minimal-plugin
Hi @reinvantveer, if you look at the maintainers/coders of the plugin you will see that the main ones are Tim and Gary: both (former) 'leaders' of the project. Others are (still) very active project members.
IF you main issue is that it is not so maintained anymore (given there are some open Pull Requests), you could ask them to take over this plugin builder maintenance maybe?
Not sure if pulling it in the main repo will make it more maintained, people will probably 'hope' that it will be given as much input as the main code then.
The crux here (I think) is somebody feeling responsible for the builder, AND having the resources/time to do the maintenance.
Another option is to make a 'new' plugin builder (maybe with not so many bells and whistles, and also adding the minimal plugin version of Martin)?
maybe we should ask @timlinux and @g-sherman to the table too :-) ?
maybe we should ask @timlinux and @g-sherman to the table too :-) ?
Hey @rduivenvoorde :) yeah I was kinda hoping to elicit a response but I don't know whether they are still active in the project
Oh and not insignificant @nyalldawson the plugin builder is already the QGIS recommended way, as stated in https://docs.qgis.org/3.16/en/docs/pyqgis_developer_cookbook/plugins/plugins.html#plugin-files. This is kinda what brought me at this QEP.
Oh and not insignificant @nyalldawson the plugin builder is already the QGIS recommended way, as stated in https://docs.qgis.org/3.16/en/docs/pyqgis_developer_cookbook/plugins/plugins.html#plugin-files. This is kinda what brought me at this QEP.
Mmm... that page needs a rewrite. 😱 . Highest priority would be removing all mentions of resources and resource compilation from it, and also removing all mentions of compiling ui files to python...
[...] removing all mentions of compiling ui files to python...
What's the recommended alternative?
Use PyQt.uic to load the UI files directly at run time
Use PyQt.uic to load the UI files directly at run time
Ok, thanks. This makes sense if you do not plan to manually edit the result of pyuic or to inherit from its result - which is kind of where the fun begins (?). Both approaches have their advantages and disadvantages.
I'd say those are advanced use cases, whereas the plugin builder generated code should be kept to be the simplest possible approach.
I think this goal is fine, the question for this QEP is more on how to get there. I'd really, really like some thoughts on this from @g-sherman and/or @timlinux. Is anyone here in the position to contact them directly? This would help a lot in deciding on whether to either
- Move the plugin builder to qgis/Qgis-Plugin-Builder
- Fork the plugin builder to qgis/Qgis-Plugin-Builder
- Move the plugin builder to QGIS-Contribution/Qgis-Plugin-Builder
- Fork the plugin builder to QGIS-Contribution/Qgis-Plugin-Builder
- Add a new maintainer to g-sherman/Qgis-Plugin-Builder
- Fork to a new {insert maintainer}/Qgis-Plugin-Builder
Either way, the documentation on https://docs.qgis.org/3.16/en/docs/pyqgis_developer_cookbook/plugins/plugins.html#plugin-files could do with some freshening up.
Does anyone here know how to contact @g-sherman or @timlinux ?
I think @timlinux is quite active. I believe he will come here for sure.
Another alternative is like what people did with QGIS Resource Sharing. It's moved from a personal (@akbargumbira's) repository to the QGIS-Contribution Github organization. See https://github.com/QGIS-Contribution/QGIS-ResourceSharing.
Another thing to do is we need to give someone who is more active to upload the new version of the plugin to the QGIS plugin repository.
Another alternative is like what people did with QGIS Resource Sharing. It's moved from a personal (@akbargumbira's) repository to the QGIS-Contribution Github organization. See https://github.com/QGIS-Contribution/QGIS-ResourceSharing.
Ah, didn't spot that one yet, good suggestion, updated the options in my comment
Hi yea I am here! I agree with all the comments from @nyalldawson @rduivenvoorde et al. Best would be to give you commit rights to the repo and let you go for it if you want to give it some love!
Hey @timlinux thanks for joining! I'd very much appreciate that. I would also need some kind of credentials to push newer versions to plugins.qgis.org if I'm not mistaken. Then we can start addressing some of the issues.
@timlinux could you add me to the repo and grant me push rights to https://plugins.qgis.org/?
Isn't this too hasty? I am curious to know if you started doing any changes to the plugin that you propose to maintain. I think having an updating version of the plugin would be the first step before asking for any rights. But that's just my opinion.
I did, starting out small, but pull requests aren't being processed at the moment (no offense meant). I do appreciate any other easy options, but at the moment I'm not seeing them. Having new maintainers on the repo would be the simplest way forward to update the plugin I suppose.
That is one way, though I think you could do your rework on your fork and push that as a new plugin? I honestly though you were asking for rights related to qgis ( as this QEP is for QGIS). If you want to take some responsibility in the plugin and start with the official repository, should this QEP still be maintained open?
Pushing to a new plugin won't get me or the community anywhere I think. The plugin builder has traction I could never achieve with a fork, since it's been the recommended way in every (as far as I have seen) QGIS official doc page on building plugins. Besides, people would have to compare and decide between forks of basically the same plugin, I don't consider this to be a service to the community if there is a simpler way by doing maintainance on the existing one. I'd be more than happy to be added as a maintainer on the existing repo, and the issue can be closed (I guess) once there are new maintainers on the project.
Maybe you can review my pull requests, @roya0045 :P ?
If you are referencing to the PR that you linked, it only seem to be a visual change, not anything that would change the behaviour. I doubt it even require any form of review.
Correct. It was issued as a starting point to start refactoring the plugin builder. There's quite a bit I would change to make it a little bit more idiomatic Python. First step for me would be to do some cleaning up in the repo.
(Updated the proposal description to include option to add maintainers to the repo)