[GRASS-stats] R interface to grass 7.1

[Roger Bivand]

On Thu, 4 Jun 2015, Edzer Pebesma wrote:

>
>
> On 06/04/2015 09:44 PM, Roger Bivand wrote:
>> On Thu, 4 Jun 2015, Rainer M Krug wrote:
>>
>>> Roger Bivand <Roger.Bivand at nhh.no> writes:
>>>
>>>> Hi,
>>>>
>>>> This is:
>>>>
>>>> http://trac.osgeo.org/grass/wiki/GSoC/2015#Neweasy-to-usecommandlineinterfaceforGRASSGIS
>>>>
>>>>
>>>> is it? Did it get accepted - I don't see this on:
>>>>
>>>> http://www.google-melange.com/gsoc/org2/show/google/gsoc2015/osgeo
>>>>
>>>> and think that only improved metadata got funded.
>>>
>>> This is true as far as I know, but it seems that Vaclac took it in
>>> his own hands to code the initial stages and he checked it into the
>>> GRASS 7.1 source.
>>>
>>> I installed GRASS 7.1 from source using homebrew (the formula is in a
>>> pending pull request) and I could execute the examples fine.
>>>
>>>> Do we know what the actual status is on this?
>>>
>>> The
>>>
>>> ,----
>>> | grass71 MAPSET --exec THE GRASS COMAND WITH WHATEVER COMES NOW
>>> `----
>>>
>>> is working, but I don't know if it has been tested a lot. For testing,
>>> the sp collection could help as there are already examples which one
>>> could run.
>>>
>>> Otherwise - no idea - but it seems to be going forward.
>>>
>>>> I'd feel that this could be a variant in rgrass7 if it becomes
>>>> available,
>>>
>>> Yes - some changes and getting rid of the initialisation of the GRASS
>>> session, and only provide the path to the grass71 executable.
>>>
>>>> but I'm not sure how it would expose the interface description.
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> grass71 --exec g.list --interface-description
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> I just tried it out.
>>>
>>> or, maybe safer,
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> grass71 PATH/TO/MAPSET --exec g.list --interface-description
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> This is only the first stage, and Vaclac seems to be very much open to
>>> suggestions and discussion on which direction this should go.
>>>
>>> The discussion is on grass-user.
>>>
>>> It seems that you are planning to move the sp packages to github - is
>>> this true?
>>
>> Just on this, no, I will give up maintaining if anyone moves the main sp
>> repository to git, and especially github, which is a proprietory
>> corporation. Git is a bad choice going forward, as the important
>> "responsibility" element is pulverised (good for projects with very
>> strong brands, so someone will be responsible, probably bad for projects
>> without strong brands with few active developers and lots of users
>> sitting on their hands). Git is usable, and can be used like svn or
>> similar centralised repositories, but is several steps backward IMO.
>> It's got popular through github because projects avoid having to host
>> their own repos. We'll see whether PROJ.4 falls apart after migration to
>> github (it's very weak already). Github mostly attracts on coolness,
>> which is often orthogonal to productive work.
>>
>> Roger
>
> I have less problems with github, and so sp might migrate one day. Right
> now, Roger and I do the majority of the work on sp, so svn on r-forge
> makes most sense. Contributors send patches, or code snippets in email.
>
> Once I see an easy way to use travis-ci for the full check on all of
> sp's reverse dependencies I will adopt that, at the cost of having to
> keep git and svn synced. Right now this check [*] takes me an absurd
> amount of time.
>
> [*] I now use:
>
> library(sp)
> demo(depend)

Using _R_CHECK_FORCE_SUGGESTS_=FALSE helps. I update/install the packages 
to check first (which draws in their c("Depends", "Imports", 
"LinkingTo")), and in checking rgeos and rgdal have reduced run times 
greatly. I also fell into the trap of setting recursive=TRUE, but that is 
not needed, as only packages referring to the target arguably need to be 
tested (if a package suggesting a package that suggests sp itself doesn't 
declare its relying on sp say for plotting something, it is in error). 
Almost all the errors turn out to be errors in the packages that are not 
caused by changes in the target, but rather careless coding or examples 
(typically unprotected library/require).

Should we set up a docker instance (or just a shell script) to run sp (and 
other) dependency checks nightly? I think the hard part is summarizing the 
findings. Project for Avignon?

Roger

>
>>
>>>
>>> Cheers,
>>>
>>> Rainer
>>>
>>>>
>>>> Best wishes,
>>>>
>>>> Roger
>>>>
>>>> On Thu, 4 Jun 2015, Rainer M Krug wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I guess you have seen the announcement from Vaclac Petras about the new
>>>>> command line interface to R. This sounds very exciting and I would like
>>>>> to start playing with the R-GRASS 7.1 interface. What would be the best
>>>>> approach concerning git / svn? should I setup my own github for this or
>>>>> should I slot in one of the spgrass repositories?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Rainer
>>>>>
>>>>>
>>>>>
>>>>> http://permalink.gmane.org/gmane.comp.gis.grass.user/51680
>>>>>
>>>>>
>>>
>>>
>>
>
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91 00
e-mail: Roger.Bivand at nhh.no