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

[Moritz Lennert]

Am 18. Dezember 2020 09:57:53 MEZ schrieb GRASS GIS <trac at osgeo.org>:
>#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 sbl):
>
> Replying to [comment:20 wenzeslaus]:
> > > Silently installing stuff can be a bit scary...
> >
> > Why do you think it is scary for GRASS GIS? pip, R, conda, apt, yum, ...
> all install dependencies of a package you asked for. Why this should not
> happen for GRASS GIS?

I would personally plead for the automatic installation of dependencies only as optional. I always prefer to install dependencies via my distribution's package manager instead of automatic installation via tools such as conda, pip or others. And I don't think it realistic to take into account all different package management systems within GRASS GIS.

So, +1 to a dependency check accompanied by the option to install the missing dependencies, but not automatic installation per se.

 




>
> Yes, you are right.
>
> So, how would we setup a requirements.txt?
>
> Should it contain different sections, like e.g.
> {{{
> GRASS_addons
>     r.area
>
> R_packages
>     ggplot2
>
> Python_libraries
>     rpy2>=1.1
>
> cmd_tools
>     iconv
>     cs2cs
>
> libraries
>     libgdal-grass
> }}}
>
> Cause the way these dependencies are installed varies a bit, with a
> dpendency_check function for each of them...
>
> Maybe better with a dependency json:
>
> {{{
> {
> "GRASS_addons": [
>     {
>       "name": "r.area"
>     }],
> "Python_libraries": [
>     {
>       "name": "rpy2",
>       "version": "1.1"
>       "version_check": ">="
>     }], ...
> }
> }}}
>
>
> In the functions we might have to think about OS specific aspects (package
> manager (incl. conda vs. pip), library names) as well as maybe versions
> (e.g. numpy>=1.17).