Feature request #3138

Add plugin autopackaging script

Added by Paolo Cavallini over 6 years ago. Updated about 1 year ago.

Status:In Progress Start Date:
Priority:Low Due date:
Assigned to:Borys Jurgiel % Done:

0%

Category:Python plugins and bindings
Target version:Future Release - Nice to have
Platform:All Resolution:
Platform version: Pull Request or Patch supplied:No
Status info:0 Tag:

Description

The current situation with plugins is rather confusing for the user: many repos, not all of them available all the time, often no easy way to understand ahow they work.
For developers the situation is also not optimal: it is difficult to notifiy bugs, easy to miss them, and difficult to fix problems in plugins other than its own.
I suggest to put all them on a trac (either a separate instance or a brach of the main QGIS trac).
A set of useful functions would then be:
  • a script for automatic packaging after any commit; this will solve the frequent problems with plugins with wrong XML data being asked to be upgraded any time, and make the dev life easier
  • a rating system, so users can tell which ones to trust more
  • download statistics, for the same purpose
  • an info page, better if open to coments

History

Updated by Andreas Neumann over 6 years ago

I will list here some of my expectations regarding the new centralized plugin repository - and related to it - some extensions on the Python plugin installer:

Central Repository

  • Quality Assurance (poor plugins are bad for QGIS reputation)
  • Status (experimental, production)
  • trac-like option to report bugs and enhancement requests
  • category
  • documentation:
    - where in the UI can the plugin be found (menu, toolbar, dialogue)
    - initial check-in date, last updated date
    - contact information - how to reach the plugin author (developer and organization/company)
    - purpose of the plugin
    - URL to further information/manual/howto
    - support options (if any)
    - what language is supported
Plugin Install Enhancements
  • reveal metadata listed above
  • way for users to comment, rate or report bugs (could also be provided by a separate web-based tool, but the plugin-installer should show a link to this other system)
  • plugins could be grouped by category
  • plugin installer could display external documentation webpage within a qtwebkit embedded in the installer
  • plugin-installer could show screenshots of the plugin

Updated by Paolo Cavallini over 6 years ago

I would add:
  • we need cooperative platform to let one or more maintainer group plugins under a reasonable number of submenus: now it is very difficult to find a plugin when installed

Updated by Borys Jurgiel about 6 years ago

  • Status changed from Open to In Progress

Updated by Giovanni Manghi over 5 years ago

  • Target version changed from Version 1.7.0 to Version 1.7.4

Updated by Giovanni Manghi almost 5 years ago

  • Target version changed from Version 1.7.4 to Version 2.0.0

Updated by Pirmin Kalberer over 4 years ago

  • Target version changed from Version 2.0.0 to Future Release - Nice to have

Updated by Giovanni Manghi about 4 years ago

  • Status changed from In Progress to Closed
  • Resolution set to fixed
  • Pull Request or Patch supplied set to No

it seems it was everything implemented, right?

Updated by Paolo Cavallini about 4 years ago

  • Subject changed from Add plugin trac + svn to Add plugin autopackaging script
  • Status changed from Closed to In Progress

Most of the features have been implemented; the autopackaging script is still missing.

Updated by Alexander Bruy about 1 year ago

  • Resolution deleted (fixed)

Do we really need autopackaging script for 3rd party plugins? What is the purpose of this script? For me it looks quite useless, I can not think of any reason why I may need to create plugin package on each commit to my GitHub or local repo.

BTW, Plugin Builder already generates makefile which allows create plugin package by running make.

Also available in: Atom