Re: [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:21 sbl]:
 > Lastly, should a dependency check function go into ''g.extension'' or
 into the python library...

 g.extension can call it, but it should be in the library - length of
 g.extension.py being one reason.

 > ...(script or pygrass)

 This looks like a new subpackage of grass. Python and R use some names
 already: setuptools, distutils, devtools, ...

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:23 sbl]:
 > I just added a draft for a python script that could take care of
 dependencies in Python (conda not tested) and R packages. Other
 dependencies (e.g. C-libraries, commandline tools) are just checked,
 neither loading of the libraries not installation is supported at the
 moment (not sure if the latter is realistic).

 The current code looks straightforward and perhaps worth trying it in
 action (you can make an addon module which installs dependencies and then
 runs g.extension on the actual module).

 However, I think this can also get really complex. What about turning this
 the other way around and focusing supporting GRASS modules which are
 Python packages installed with conda or pip like itzi? They would just use
 the existing systems for dependencies. Still, g.extension could use
 handle_dependencies.py logic, but it would use it to install the module
 rather than the dependencies.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS module version strictness (libgrass_gis)

[Markus Metz]

On Fri, Mar 5, 2021 at 8:30 PM Benjamin Ducke  wrote:
>
> Dear Devs,
>
> I am trying to find a way to inject GRASS modules (C code)
> compiled  in a GRASS 7 source tree into an already installed
> version of GRASS. Even if I compile in a GRASS 7.8.5 tree and
> then copy into a GRASS 7.8.5 (i.e. exact version match)
> installation, I get this:
>
> ERROR: Module built against version 2021-03-04T21:51:47+00:00 but trying
to
> use version 2021-01-01T10:33:43+00:00. You need to rebuild GRASS
GIS
> or untangle multiple installations.

GRASS uses the git revision to check if separately compiled modules are
compatible with the current version. If the git revision is not available,
the date of compilation is used instead. This is a safety measure to ensure
binary compatibility. The idea of using the date of compilation as
surrogate is targeted at branches under development and might not be
appropriate for released versions that do not change any more. Apparently
we need to distinguish between released versions and versions under
development and adjust the check for binary compatibility accordingly.

Markus M

>
> This is coming from 'libgrass_gis'.
>
> Apparently, GRASS keeps exact timestamps of the binaries and
> won't allow any mixing.
>
> Is it really necessary to be this strict about build versions?
> Would it be possible to relax this, so that a module compiled with
> GRASS 7.8.a can be run under GRASS 7.8.b?
>
> I worked around this issue with some LD_LIBRARY_PATH "magic",
> and even running 7.8.1 binaries in a 7.8.5 installation seems
> to work flawlessly.
>
> Background: I am trying to find a way to provide sets of
> additional modules, that are not part of the GRASS base
> distribution, for injection into an existing GRASS installation.
> This is exceedingly hard if all dependencies have to be
> exact matches; especially if the modules are to be injected
> into a version of GRASS bundled with QGIS.
>
> Best,
>
> Ben
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS GIS single layout (GSoC 2021)

[L.Kladivova]

Hello GRASS devs and OSGeo mentors,


I hope you are all well. :-) I'm writing to the group due to Google Summer
of Code 2021. I would love to participate, this time as a PhD. student of 
geodesy and cartography at CTU.


 

About two months ago, I successfully ended up my master studies, which was
aimed at improving the first-time user experience in GRASS, and of which you
were all a bit part because you participated very often in surveys that 
helped me (us) to move the GRASS GUI forward. :-)


 

The topic of GRASS single layout  which I would like to deal with was heard
several times in surveys, and in terms of importance, it seems that this 
topic has the highest priority in terms of GRASS GUI.




However, it is a very extensive topic and will mainly mean a large
refactoring of the GUI code. I have already started with it within the PRs
https://github.com/OSGeo/grass/pull/1321, and https://github.com/OSGeo/
grass/pull/1437. I also know that there is probably another applicant, but I
believe that we can work on it together. And I even think that the
cooperation can be a very positive experience since the topic is really very
broad. :-)


 

For Vero: Regarding the presentation for FOSS4G, I would like to contribute.
:-)





Have you all a nice evening.





Best,


Linda___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev