[Qgis-developer] SEXTANTE backends

Alexander Bruy alexander.bruy at gmail.com
Tue Apr 17 09:15:38 EDT 2012


Hi,

2012/4/17 Julien Malik <julien.malik at c-s.fr>:
> Hi,
>
> Does the Qgis plugin system support dependency between plugin ?

AFAIK there is no such support, but this easily can be solved at plugin
level. For example, SAGA module interface plugin needs QGIS Processing
Framework plugin and check in __init__.py for this module using try-except
statement

try:
  import saga_api
except ImportError:
  PyQt4.QtGui.QMessageBox.warning(window,
      window.tr("Could not find SAGA python bindings"),
      window.tr("<html>Could not find the Python bindings for "
                "SAGA, which are required to run the this plugin.<br/>"
                "See instructions on how to install them in the "
                "<a href=\"https://github.com/polymeris/qgis/wiki/"
                "How-to-install-the-SAGA-Python-Bindings\">"
                "QGIS SAGA interface wiki</a></html>"))
    raise ImportError("Missing SAGA")

Same approach can be used for SEXTANTE.

> Now that there is (already !) a lot of backends integrated directly into the
> core plugin, I guess there will be more and more people proposing
> improvements. I think moving to a DVCS would help, so that people can
> "pull-request" you, with all the advantages of dvcs : lower down patch work
> for you, honor contributors in the code base by preserving authoring, help
> for work on more mid/long-term feature before integration into your
> reference repository, etc...
> If my understanding is ok, the redmine instance can host a git repository,
> at the cost of two mouse clicks.
> Victor, others, what's your opinion on this ?
I also support this idea. This can be also github not only redmine.

> About integration of the binaries, as discussed at the HF, I'm afraid this
> would be impossible to maintain. Probably even impossible to do at all.
> It makes no sense on linux where the habit is to install software
> system-wide through the package manager.
> My opinion is that it is a packager-related issue, and should not interfere
> with the plugin deployment.
> Even for windows, a package can be a bit more than just a zip to unzip.
> You'll be reimplementing osgeo4w-setup inside your plugin if you take that
> road.
All external binary packages should be installed ONLY by user using system
package manager (or installer). IMO, SEXTANTE itself should only provide
interface for this programs. If necessary backends can check for required
binaries/bindings on start and show message when this binaries/bindings are
missed.

> For windows, I see there is already a "qgis-grass-plugin" osgeo4w package.
> Maybe there could be a qgis-sextante-providers package, sort of virtual
> package depending on all the necessary packages for sextante backends ?
> Then, if it proves usefull and stable enough, it could even be integrated in
> the standalone qgis installer so that people downloading qgis out of osgeo4w
> also can get saga/otb/... easily ?
Well, I think SEXTANTE with some backends should go into QGIS core. All other
backends can be available as additional modules in plugin repo.

-- 
Alexander Bruy


More information about the Qgis-developer mailing list