search

qgis / QGIS-Enhancement-Proposals

QEP's (QGIS Enhancement Proposals) are used in the process of creating and discussing new enhancements for QGIS
117 stars 37 forks source link

Adopt g-sherman/Qgis-Plugin-Builder #223

Open reinvantveer opened 3 years ago

reinvantveer commented 3 years ago

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:

Plus:

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:

Backwards Compatibility

Any QGIS 3 version

Votes

(required)

roya0045 commented 3 years ago

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.

reinvantveer commented 3 years ago

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.

nyalldawson commented 3 years ago

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!

reinvantveer commented 3 years ago

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.

nyalldawson commented 3 years ago

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

rduivenvoorde commented 3 years ago

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)?

rduivenvoorde commented 3 years ago

maybe we should ask @timlinux and @g-sherman to the table too :-) ?

reinvantveer commented 3 years ago

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

reinvantveer commented 3 years ago

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.

nyalldawson commented 3 years ago

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. :scream: . 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...

s-m-e commented 3 years ago

[...] removing all mentions of compiling ui files to python...

What's the recommended alternative?

nyalldawson commented 3 years ago

Use PyQt.uic to load the UI files directly at run time

s-m-e commented 3 years ago

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.

nyalldawson commented 3 years ago

@s-m-e

I'd say those are advanced use cases, whereas the plugin builder generated code should be kept to be the simplest possible approach.

reinvantveer commented 3 years ago

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

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 ?

ismailsunni commented 3 years ago

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.

reinvantveer commented 3 years ago

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

timlinux commented 3 years ago

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!

reinvantveer commented 3 years ago

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.

reinvantveer commented 3 years ago

@timlinux could you add me to the repo and grant me push rights to https://plugins.qgis.org/?

roya0045 commented 3 years ago

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.

reinvantveer commented 3 years ago

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.

roya0045 commented 3 years ago

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?

reinvantveer commented 3 years ago

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 ?

roya0045 commented 3 years ago

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.

reinvantveer commented 3 years ago

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.

reinvantveer commented 3 years ago

(Updated the proposal description to include option to add maintainers to the repo)