Closed rsbivand closed 3 years ago
@florisvdh Here is a Windows binary built locally, and tested on Windows 10 for an almost current WinGRASS and a bit older OSGeo4W. On Linux and both Windows variants, the python handling seems improved. I'm unsure what will happen for GRASS < 7.8, which used python2 not python3. If your collaborators have access, please try, also with execGRASS("g.gui")
.
Thanks for the work @rsbivand. Starting to test in Linux, a bug appears in initGRASS()
:
library(rgrass7)
#> Loading required package: XML
#> GRASS GIS interface loaded with GRASS version: (GRASS not running)
gisbase_grass <-
if (.Platform$OS.type == "windows") link2GI::paramGRASSw()$gisbase_GRASS[1] else {
link2GI::paramGRASSx()$gisbase_GRASS[1]
}
gisbase_grass
#> [1] "/usr/lib/grass78"
list.files(gisbase_grass)
#> [1] "AUTHORS" "bin" "CITING"
#> [4] "contributors_extra.csv" "contributors.csv" "COPYING"
#> [7] "demolocation" "docs" "driver"
#> [10] "etc" "fonts" "GPL.TXT"
#> [13] "gui" "lib" "locale"
#> [16] "scripts" "translators.csv.gz"
initGRASS(gisBase = gisbase_grass,
home = tempdir())
#> Error in nchar(OSGEO4W_ROOT): object 'OSGEO4W_ROOT' not found
Created on 2021-01-06 by the reprex package (v0.3.0)
While debugging, it seems to happens because the OSGEO4W_ROOT
object does not exist in Linux, when running line 230:
BTW no need to provide the Windows binary build; remotes::install_github("rsbivand/rgrass7")
will work OK for testing in Windows.
OK, thanks, I was looking at the WinGRASS/OSGeo4W contrast. And I do not trust remotes, i always use R CMD INSTALL --build
which IIUC remotes does not do, and most Windows users do not have RTools.
OK, thanks for the hints.
Intrigued by your comment on remotes, I had a quick look. (I'm writing it down for later reference) It seems (but that should be verified) that it essentially tries a R CMD INSTALL
through processx()
, run by callr::rcmd_safe()
in a separate R process, which itself is called by pkgbuild::build()
through pkgbuild::rcmd_build_tools()
. remotes seems to prefer the latter, and if not, remotes uses callr::rcmd()
directly. However, that is a very superficial analysis from looking through R code at GitHub - a lot is happening along the way to adjust settings (and hence the outcome is not clear from the code at first sight). So it would need a debug cycle to actually verify the command that is sent.
Certainly, it takes a long way compared to directly calling R CMD
, which gives you direct control over what is happening.
Have tested this in Windows 7, with OSGeo4W GRASS and R 4.0.3. Launching GRASS GUI independently (from the start menu, i.e. with the installed batch file) works. No success from RStudio within OSGeo4W shell:
> library(rgrass7)
Loading required package: XML
GRASS GIS interface loaded with GRASS version: (GRASS not running)
> gisbase_grass <- "C:/OSGeo4W64/apps/grass/grass78"
> list.files(gisbase_grass)
[1] "AUTHORS" "bin" "CHANGES"
[4] "CITING" "config.status" "contributors.csv"
[7] "contributors_extra.csv" "COPYING" "demolocation"
[10] "docs" "driver" "etc"
[13] "fonts" "GPL.TXT" "gui"
[16] "include" "INSTALL" "lib"
[19] "locale" "REQUIREMENTS.html" "scripts"
[22] "share" "tools" "translation_status.json"
[25] "translators.csv"
> initGRASS(gisBase = gisbase_grass,
+ home = tempdir())
gisdbase C:/Users/FLORIS~1/AppData/Local/Temp/RtmpAbxW6V
location file21b42d9e3234
mapset file21b41ebb2163
rows 1
columns 1
north 1
south 0
west 0
east 1
nsres 1
ewres 1
projection:
XY location (unprojected)
> execGRASS("g.gui")
Traceback (most recent call last):
File "C:/OSGeo4W64/apps/grass/grass78/gui/wxpython/wxgui.py", line 32, in <module>
from core.utils import registerPid, unregisterPid
File "C:\OSGeo4W64\apps\grass\grass78\gui\wxpython\core\utils.py", line 29, in <module>
from core.gcmd import RunCommand
File "C:\OSGeo4W64\apps\grass\grass78\gui\wxpython\core\gcmd.py", line 43, in <module>
from win32file import ReadFile, WriteFile
ImportError: DLL load failed: Kan opgegeven module niet vinden.
Launching <wxpython> GUI in the background, please wait...
WX GUI lauched - Close GUI manually when finished
A message comes through that the GUI has launched, however it didn't. The above problems may have to do with other things than the PYTHON env variables though, possibly OSGeo4W-specific.
It's certainly not an essential thing to be able to run g.gui from R.
@toonhub: you use more or less the same Windows setup (Win7+OSGeo4W GRASS). Can you run the above lines - do you get the same result? @hansvancalster: what happens in Win7 +WinGRASS (standalone)?
I can retest in Linux after the problem for Linux is fixed. Beside Mint 20 (Focal), I still have a partition with Mint 18 (Xenial) that has GRASS 7.6, so can try that too.
It should be added that official support for Windows 7 has stopped since nearly a year (unless one purchases extended security updates). So any issues that are Win7-only may not be worth the trouble.
Besides the same will be true for Ubuntu Xenial (16.04) in a matter of months. Ubuntu-based distros since Bionic (18.04) have easy access to precompiled GRASS 7.8 through the ubuntugis-unstable PPA, but Xenial only has 7.6 there.
Since this didn't work before, it is not a regression for GRASS 7.6 users. Unless it can be shown to detract from pre-existing usability for 7.6, there is absolutely no need to do anything. Should I install GRASS 7.6 on Windows 10 to check for a regression, or is there no regression? 0.2-4 source is on CRAN now.
Part of the implicit bargain of FOSS is that users keep up with version updates, to be able to contribute useful reports aiding further development. FOSS may try to keep things that ran before running, but back-porting new functionality to EOL platforms really isn't a priority.
For the Win7 OSGeo4W 7.8 example, please try with rgrass7 0.2-3 first, with the option to permit no flags or parameters, then with 0.2-4. If they are the same, there is no regression. Please also try starting RStudio in the OSGeo4W console, Rgui in the OSGeo4W console, and command line R in rge OSGeo4W console. I don't have Win7, so cannot replicate.
Thank you for the CRAN release :tada: . (I missed that you already solved the initGRASS()
problem for Linux)
Just re-tested the earlier code in Mint 20 (Focal), and it now works perfectly :+1:. execGRASS("g.gui")
runs nicely, thank you.
Will test this (and stringexecGRASS
) for GRASS 7.6 in Linux (Xenial) and look at your 0.2-3/0.2-4 recommendations for Win7 OSGeo4W ASAP.
I can confirm that - after updating to rgrass7 v0.2-4 - execGRASS("g-gui")
also works on my system with Windows 7 and a stand-alone installation of GRASS. Nice to know that this is possible :+1:
Test results for execGRASS("g.gui")
and stringexecGRASS()
on Xenial with GRASS 7.6.1 below. Successful!
Do note, there are some warnings from GRASS about the missing GRASS_ADDON_BASE
environment variable. It appeared in Focal as well. However, it is no show-stopper!
Windows 7 + OSGeo4W GRASS 7.8 results for the Win7 installation on my (multiboot) PC. Due to history specifics of this Win7 installation (it is not new, although rarely used), results could still be different when run on another machine with a Win7/OSGeo4W setup (just a tiny chance I guess).
In this setup, execGRASS("g.gui")
consistently does not launch the GRASS GUI, both for rgrass7 0.2-3 and 0.2-4, although the standard output/error differs between both package versions. Per package version, results are identical between R/Rgui/RStudio (RStudio also in interactive use, not shown here). All programs are started from within the OSGeo4W shell.
stringexecGRASS()
also worked successfully in this setup (rgrass7 0.2-4).
GRASS GUI successfully launches on this system when started from its batch file (i.e. windows start menu).
Test script for rgrass7 0.2-3:
library(rgrass7)
invisible(set.stop_on_no_flags_parasOption(FALSE))
gisbase_grass <- "C:/OSGeo4W64/apps/grass/grass78"
initGRASS(gisBase = gisbase_grass, home = tempdir())
execGRASS("g.gui")
Test script for rgrass7 0.2-4:
library(rgrass7)
gisbase_grass <- "C:/OSGeo4W64/apps/grass/grass78"
initGRASS(gisBase = gisbase_grass, home = tempdir())
stringexecGRASS("g.proj -w -f epsg=4258", intern = TRUE)
execGRASS("g.gui")
Returned Dutch standard error means: 'The system cannot find the specified path'.
Returned (partially) Dutch standard error means: 'ImportError: DLL load failed: Cannot find specified module'.
I agree there is no need to pursue this further for Windows 7. It's good to know that it works on Windows 10, and it's a bonus that it works on Windows 7 with WinGRASS.
OK, I'll close this now. I wonder whether OSGEO4W differs from OSGEO4W64.
initGRASS()
makes outdated assumptions about PYTHON handling. It setsGRASS_PYTHON
andPYTHONPATH
in an outdated way. (Continued from #20).