On this page you find a probably not complete list of available python plugin repositories. Some of them might already be listed in the plugin installer by default.
QGIS Official and Contributed Repositories¶
- QGIS Official Repository http://pyqgis.org/repo/official
- QGIS Contributed Repository http://pyqgis.org/repo/contributed
Starting from QGIS 1.8 (not yet released at the time of writing) the new official repository will be added to the list of default repositories.
The new repository is hosted at:
- QGIS New Official Repository http://plugins.qgis.org
Add the following to your plugin install repo list if you are running a version <1.8 http://plugins.qgis.org/plugins/plugins.xml to get access to the new plugin repo.
The documentation about the supported metadata and the validation rules implemented in the new plugin repository are listed here:
https://github.com/qgis/qgis-django/blob/master/qgis-app/plugins/docs/introduction.rst
External Author Repositories¶
If you developed a python plugin for QGIS and want to make it available for other users, please add a link to your repository to the list below. The QGIS User Guide tells you how to integrate new repositories into the QGIS Plugin Installer.
- Faunalia Repository http://www.faunalia.it/qgis/plugins.xml
- Carson Farmer's Repository http://www.ftools.ca/cfarmerQgisRepo.xml
- Aaron Racicot's Repository http://qgisplugins.z-pulley.com/
- Barry http://www.maths.lancs.ac.uk/~rowlings/Qgis/Plugins/plugins.xml
- Martin http://mapserver.sk/~wonder/qgis/plugins-sandbox.xml
- GIS-Lab.info http://gis-lab.info/programs/qgis/qgis-repo.xml
- Volkan Kepoglu's Repository http://ggit.metu.edu.tr/~volkan/plugins.xml
- Bob Bruce's Repository http://www.mappinggeek.ca/QGISPythonPlugins/Bobs-QGIS-plugins.xml
- Sourcepole repository http://build.sourcepole.ch/qgis/plugins.xml
- Dimitris Kavroudakis repository http://www.dimitrisk.gr/qgis/plugins.xml
- Dane Springmeyer - http://qgis.dbsgeo.com/
- gis-plugins.nl - http://www.gis-plugins.nl/pyqgis
Ideas for improvement¶
Carson Farmer:
3rd party repository authors should be maintaining their own repositories, and if problems occur (site down, etc.) then their connections will simply time-out, and users won't be able to download their plugins.
As for the hand-made xml data: one solution would be to create a very simple python plugin that parses their init.py file and extracts the relevant info correctly.
I'd also like to suggest that the 'add 3rd party repos' button should simply fetch a list of 3rd party repositories from the QGIS server (some sort of list created by an online submission system). That way there is no hard-coding of repos by Borys, and it's fair for all authors. We can certainly have a few different lists (i.e. well tested repos, experimental repos, and untested repos). And as more people use the plugins from a particular repo, the repo can be moved up the hierarchy. Obviously this type of a system would lend itself well to eventually adding the facilities for users to rate plugins etc.
Maybe this is simply too much work at this stage, but I'd like us to also consider other options...
Paolo Cavallini:
- a trac for plugin bugs - currently there is no reliable way to point out bugs and issues, to know which one was fixed, etc.
- a way to cooperate on plugins: there are easy fix and improvements that cannot be applied because in the current structure only the owner of the plugin can; as a result, several forking has already occurred (which is bad both for devs and for users).
I agree we should encourage, not discourage, individual contributions. On the other hand, we should make it easier to collaborate on the development and bugfixing of individual plugins.
I see two choices here:- keeping the existing system, and create a script to sync the uploaded plugin to an ad hoc svn+trac: no impact on contributors, but we keep the possibility of fixing the plugins when needed, arranging them in menus and submenus, open tickets, etc.
- replacing the current system with a different one, possibly with the seme or similar interface, that loads the plugin directly on the above mentioned svn+trac.
Of course contributors can always add their repo at will: Our system should be in place just to help collaborating, not to force anyone.
At the same time, a system for:- counting the number of downloads
- giving a rank
- sharing comments
- sorting by popularity, number of downloads, date
- tagging and searching
is something useful, and everybody is expect such a system (see eg the FireFox
addons: https://addons.mozilla.org/it/firefox/).
Borys Jurgiel:
So the compromise would be to offer to authors of small repositories a more
convenient, robust and reliable solution and try to encourage them to join it.
This way we can limit the number of external repositories added by the button
to really necessary 3-5.
Other Authors will have a choice:
- to join the community repo
- to maintain their own, but not included by the button
- to maintain their own and justify it's reasonable to add it
I understand the need of diversity, but users should trust that clicking this
unfortunate button they won't be flooded by dozens unreliable repositories :)