Closed raff-k closed 2 years ago
Could you please try install.packages("rgrass7", repos="http://R-Forge.R-project.org")
? https://r-forge.r-project.org/scm/viewvc.php/pkg/rgrass7/R/initGRASS.R?root=spgrass&r1=55&r2=67 shows changes affecting the junk
file. They were needed for OSGEO4W directory choices IIRC.
Thank you for the quick reply. The issue I mentioned is based on the changes in yellow from line 115-121. I do not know the reason why you had to change, but I assume a working example could be:
fn_gisrc <- "junk"
if (isTRUE(file.access(Sys.getenv("HOME"), 2) == 0)) {
# instead of: if (isTRUE(file.access(".", 2) == 0)) {
Sys.setenv(GISRC = paste(Sys.getenv("HOME"), "\\.grassrc7", sep = ""))
# Instead of: Sys.setenv(GISRC = fn_gisrc)
}
else {
warning("working directory not writable, using tempfile for GISRC")
Sys.setenv(GISRC = paste0(tempfile(), "_", fn_gisrc))
}
I am wondering, if it is really necessairy to use the current working directory for the GISRC-file? ('"."')
The specific difficulty was with OSGEO4W settings. On unix-type systems (all but Windows), it would be usual to put project files in the current directory, not $HOME. I cannot remember whether OSGEO4W didn't set HOME to a non-writable directory. I will not have access to a Windows system until the end of next week to try things out.
Could you please be more explicit about the parallellising issue? How many R or GRASS sessions do you intend to run and which is controlling what?
And we can carry on using this issue, but rgrass7 does live on R-Forge, not here.
@tim-salabim : Could we try to coordinate this, as link2GI is implicated? Re.: https://github.com/r-spatial/discuss/issues/18 ? I expect to be working on rgrass7 until mid August among other things. This is also https://github.com/r-spatial/link2GI/issues/20 @gisma
Of course, are you thinking of migrating rgrass7 from R-Forge to github? Both you and @gisma are members of r-spatial already. Following each others updates to the repos should be easier that way
Yes, migration to github sooner, and r-spatial when sf/stars ready and backwards sp-compatible (that is the aim, anyway).
I have it on screen but no stable internet during the weekend...
Could you please be more explicit about the parallellising issue? How many R or GRASS sessions do you intend to run and which is controlling what?
I plan to run for each worker (or core) a unique location to account for the peaceful coexistence.
Since rgrass7::initGRASS()
initiates the GISRC-environment (as junk-file) all the time in the current working directory, the GISRC's of the different locations overwrite each other. This causes errors initializing GRASS GIS in parallel-processing.
Even if one set a path by the home
-parameter, the junk-file is written to the current working directory. To set a proper and unique GISRC-file for each location, one has to switch the current working directory to a specified folder every time before executing rgrass7::initGRASS()
. However, this behaviour is only the case for windows.
And we can carry on using this issue, but rgrass7 does live on R-Forge, not here.
That's great. Thank you :-)
OK, thanks, I'll think about how to disentangle this.
I am using the Cran-Version rgrass7_0.1-12. Under Windows I discoverd that the GISRC-environment is all the time stored as "junk"-file in the current working directory, even when the home-path is explicitly set. Moreover, the path to the junk-file is not properly set in the system-environment. Instead of the complete path, only "junk" is written (see
Sys.getenv("GISRC")
). This causes troubles when one is changing the working directory but still executing GRASS GIS operations.By debugging, I discover, that at the beginning the path is properly set by
Sys.setenv(GISRC = paste(Sys.getenv("HOME"), "\\.grassrc7", sep = ""))
. However, subsequently the information is overwritten byfn_gisrc <- "junk"
followed bySys.setenv(GISRC = fn_gisrc)
. Here, junk is automatically written to the current working directory (cat("GISDBASE:", getwd(), "\n", file = Sys.getenv("GISRC"))
).In the following a hopefully reproducible code to demonstrate the issue: