[GRASS-dev] [GRASS GIS] #2895: Define dependencies for GRASS addons

[GRASS GIS]

#2895: Define dependencies for GRASS addons
--------------------------+-------------------------
  Reporter:  pmav99       |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  7.8.3
 Component:  Default      |    Version:  unspecified
Resolution:               |   Keywords:  g.extension
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by wenzeslaus):

 Replying to [comment:24 hcho]:
 > Replying to [comment:23 sbl]:
 > {{{
 > cmd R 3.4 >=
 > cmd cmdfail 3.4 >=
 > R_package igraph 0.7.1 >=
 > R_package R_fail_test 0.7.1 >=
 > }}}
 > looks unnatural and error-prone. Would it be possible to change this
 format to
 > {{{
 > cmd R >= 3.4
 > cmd cmdfail >= 3.4
 > R_package igraph >= 0.7.1
 > R_package R_fail_test >= 0.7.1
 > }}}

 Instead of adding another dependency format which is a custom format, I
 would suggest at least using an existing general format, e.g., JSON.
 However, going a step further might be even better, Conda has a somewhat
 general dependency file format (environment.yml) or, alternatively, tools
 like [https://mybinder.readthedocs.io/en/latest/using/config_files.html
 Binder] take advantage of existing dependency formats, i.e., use
 requirements.txt for Python, DESCRIPTION for R, environment.yml for Conda,
 etc. When you consider setup.py for Python, this transitions nicely to my
 suggestion about supporting modules which are packages.

 > Also, how about defining dependency information inside modules
 themselves instead of using an external file? We already have
 `G_option_*()` functions to handle option dependency. Maybe,
 `G_module_requires(void *first, ...), G_module_requires_python(void
 *first, ...), G_module_requires_r(void *first, ...)` ... Then, add a new
 global flag `--dependencies` to spit out dependency information?

 In this case, you would have to compile and run the module before figuring
 out the dependencies. This would not be possible for C/C++ and it still
 insist on lazy imports. Even if we say these two issues are not bothering
 us in the end given other issues, this would be extra confusing since it
 is exactly the opposite of what any other dependency/packaging system is
 doing.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2895#comment:26>
GRASS GIS <https://grass.osgeo.org>