History

This is the entry point for those interested in working on the plugin repository. The plugin repository is a django application. The source code for the application is hosted on github:

https://github.com/qgis/qgis-django

If you would like write access to the above repository, please contact Tim Sutton ().

Note the repository was changed from a personal repository to a community one - please note the new url above.

The pieces

Version 1.0

This section lists wanted features for the first version of the plugin repository. Once everything is on its place, we can probably switch from the original repository now hosted at pyqgis.org and require all the plugin developers to upload the plugins to the new repository. From that time, no more public 3rd party repositories will be encouraged - everyone should be happy to use the official repository :-)

For easy usage of the repository, a command line tool (supposedly a python module) should be provided with qgis that will upload new plugin version, given just the package file, changelog and username/password. Later we could even create a plugin for convenience with simple GUI for instant publishing.

List of views and actions in the plugin repository application:
  • views for registered users:
    • list my plugins
    • plugin details with editing (remove incorrect upload, delete plugin, add owner etc.)
  • actions for registered users:
    • add plugin / edit plugin
    • upload new plugin version
  • views for all users:
    • list plugins (main page)
      • show either featured (default) or all plugins
      • show plugins of a particular user
      • sorting: recently added/updated, most downloaded
    • show plugin details
    • repository xml compatible with original repository
Notes:
  • user authentication - osgeo LDAP should be used (no more new logins please!), using HTTPS so that the passwords are not visible (see http://packages.python.org/django-auth-ldap/)
  • there is always one or more owners for a plugin, any owner of a plugin can add new people as co-owners. Only owners are allowed to upload new versions, edit or completely remove a plugin. If the owner of a plugin disappears, a new owner could be assigned for the plugin by the admins
  • download counts
    • downloading of plugin packages should be redirected in order to calculate download count directly (without accessing web server stats)
  • featured plugins
    • admins might want to mark interesting (and well behaving) general purpose plugins as featured to make them more visible from the less interesting ones
  • trusted users
    • a simple protection from malicious users: everyone is at the beginning marked as untrusted, the uploaded plugins are not visible until an admin doesn't review the code and mark the user as trusted. Plugins uploaded by trusted users are immediately visible - this still leaves some space for malicious users (first upload something good, get trusted, then upload something bad), however we don't have resources to check all the updated plugins. Malicious users - once detected - get blocked forever.
  • plugin uploading: user should only select a file for upload and provide a changelog - the rest should be handled on the server
  • plugin versioning: for each plugin, the entire release history will be kept. By default users will see only the last version. For plugins that make distinction between development (experimental?) and stable versions, there should be an option when uploading the plugin whether that is a development version. The owner should be able to mark also manually which version is the last stable and last development (experimental) version.
  • upload checks
    • check that the uploaded file has an acceptable size (e.g. < 1MB)
    • check that the uploaded file is valid zip archive
    • check that the plugin exists, user is owner of the plugin, this version does not exist yet, ...
    • parse plugin metadata and update the plugin details from it: nowadays the plugins store metadata in init.py file, but it has been suggested to migrate them to a separate text file (so that both repository and plugin manager in qgis will have easier work). Of course a compatibility python method should be kept in init.py file that would create the metadata info from the text file. Syntax of the metadata file should be user-readable and editable (i.e. no XML!), probably the best choice will be the format used in ConfigParser Python module.
Preliminary suggested table structure (incomplete):
  • users: owner_id, name, mail, trusted (connected to LDAP)
  • plugins: plugin_id, name, description, last_version, last_update_time, create_time
  • plugin_versions: plugin_id, version, upload_time
  • plugin_owners: plugin_id, owner_id

Version 2.0