#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>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev