<div dir="ltr">Thanks for this Vaclav. I'm confused as to why sklearn is not being found by testing for the presence of the module, but I can make an update to use the try-except method to get around this.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 27, 2016 at 8:00 AM, Vaclav Petras <span dir="ltr"><<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 27, 2016 at 7:18 AM, Markus Neteler <span dir="ltr"><<a href="mailto:neteler@osgeo.org" target="_blank">neteler@osgeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>(I noted that various GRASS scripts use different ways for this check,<br>
the test for 3rd party packages should be standardized.)</div></blockquote></div><br><br></div><div class="gmail_extra">I so far promoted lazy import* as a solution to these dependencies. The important part is that import happens after calling grass.script.parser(), so for manual and GUI, you don't need to have the dependencies at all. For simple modules (with dependency usage limited to main() function), the import** is done in main() after parser() call and try-except with ImportError is used to catch the missing dependency and report an error to the user (example: r.colors.cubehelix***). More complicated modules (with explicit dependency usage outside of main() function) must be solved on a case-to-case basis (examples: <a href="http://v.class.ml" target="_blank">v.class.ml</a> and v.class.mlpy).<br><br></div><div class="gmail_extra">Older discussions:<br></div><div class="gmail_extra"><br><a href="https://lists.osgeo.org/pipermail/grass-dev/2015-February/073734.html" target="_blank">https://lists.osgeo.org/pipermail/grass-dev/2015-February/073734.html</a><br><a href="https://lists.osgeo.org/pipermail/grass-dev/2016-March/079610.html" target="_blank">https://lists.osgeo.org/pipermail/grass-dev/2016-March/079610.html</a><br><br></div><div class="gmail_extra">Examples:<br></div><div class="gmail_extra"><br><a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.colors.cubehelix/r.colors.cubehelix.py#L186" target="_blank">https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.colors.cubehelix/r.colors.cubehelix.py#L186</a><br><a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.flexure/r.flexure.py?rev=64452" target="_blank">https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.flexure/r.flexure.py?rev=64452</a><br><a href="https://trac.osgeo.org/grass/changeset/66482/" target="_blank">https://trac.osgeo.org/grass/changeset/66482/</a><br><br></div><div class="gmail_extra">Vaclav<br><br><br></div><div class="gmail_extra">* By lazy import I mean an import which is not done at the beginning of the file, but somewhere in some function only right before it is actually needed.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">** I think that import with try-except is just more straightforward than testing the presence of the module/package before the import. It also follows "it is easier to ask for forgiveness than for permission" (EAFP), so one can say that it is more Pythonic.<br></div><div class="gmail_extra"><br>*** r.colors.cubehelix is actually not the basic example, because it provides fallback when the dependency is not available and shows just warning and an error but without exiting (uses warning() and error() and it does not use not fatal()).<br></div></div>
</blockquote></div><br></div>