NLMR is not available on CRAN anymore

[bitbacchus]

Apparently, spatstat is split up differently, now. We do not need spatstat.core anymore but spatstat.random.

https://cran-archive.r-project.org/web/checks/2022/2022-03-05_check_results_NLMR.html

[bitbacchus]

Uh, this is fixed, already in #90, I totally forgot. Needs to be pushed to CRAN

[mhesselbarth]

Yeah the spatstat splitting starts to get a bit annoying...

[Stavooo]

When trying to install NLMR I get - package 'NLMR' is not available for this version of R Can it be related to this issue? Would be a great help if the package is available on CRAN again.

[z3tt]

Our apologies @Stavooo. Yes, due to the recent changes in the spatstat package our package is currently not available on CRAN via the ususal install.packages() command. We will work on it so that the NLMR package is easily accessible soon again.

In the meantime, you can install the development version from GitHub if you need to:

# install.packages("devtools")
devtools::install_github("ropensci/NLMR")

[Stavooo]

I am working on a cluster and for some reason, I also get an error with devtools on the cluster.

[z3tt]

What is the exact error? Does remotes::install_github("ropensci/NLMR") work?

[bitbacchus]

We had a conversation via e-mail, already. Here is the summary:

OS: CentOS Linux 7 (Core) R version 4.1.2 (2021-11-01) BLAS/LAPACK: /trinity/shared/easybuild/software/FlexiBLAS/3.0.4-GCC-11.2.0/lib64/libflexiblas.so.3.0 stats graphics grDevices utils datasets methods base Rcpp_1.0.8.3 compiler_4.1.2 tools_4.1.2 curl_4.3.2 remotes_2.4.2

Error message: "Failed to install 'unknown package' from GitHub: Line starting 'SystemRequir ...' is malformed!"

remotes::install_github("ropensci/NLMR", dependencies = TRUE, upgrade = "never"), same with devtools::install_github (which is the same, imho).

Works locally just fine.

I'm out of ideas...

[mhesselbarth]

Is this the same issue why NLMR is not on CRAN anymore or are they unrelated?

[JonathanGehret]

Hi, I'm also currently struggling to install the package. install.packages("NLMR") still doesn't work for me while devtools::install_github("ropensci/NLMR") and remotes::install_github("ropensci/NLMR") lead to following error:

> remotes::install_github("ropensci/NLMR")
Downloading GitHub repo ropensci/NLMR@HEAD
✔  checking for file 'C:\Users\Jojo\AppData\Local\Temp\RtmpwbvsTn\remotes4308673a37d3\ropensci-NLMR-b6ada93/DESCRIPTION' (375ms)
─  preparing 'NLMR': (3s)
✔  checking DESCRIPTION meta-information ... 
─  cleaning src
─  checking for LF line-endings in source and make files and shell scripts (456ms)
─  checking for empty or unneeded directories
   Omitted 'LazyData' from DESCRIPTION
─  building 'NLMR_1.1.tar.gz'

Installiere Paket nach ‘C:/Users/Jojo/AppData/Local/R/win-library/4.2’
(da ‘lib’ nicht spezifiziert)
* installing *source* package 'NLMR' ...
** using staged installation
** libs
/mingw64/bin/g++  -std=gnu++11 -I"C:/PROGRA~1/R/R-42~1.0/include" -DNDEBUG  -I'C:/Users/Jojo/AppData/Local/R/win-library/4.2/Rcpp/include'   -I"c:/rtools42/x86_64-w64-mingw32.static.posix/include"     -O2 -Wall  -mfpmath=sse -msse2 -mstackrealign  -c RcppExports.cpp -o RcppExports.o
/bin/sh: line 1: /mingw64/bin/g++: No such file or directory
make: *** [C:/PROGRA~1/R/R-42~1.0/etc/x64/Makeconf:259: RcppExports.o] Error 127
ERROR: compilation failed for package 'NLMR'
* removing 'C:/Users/Jojo/AppData/Local/R/win-library/4.2/NLMR'
Warning message:
In i.p(...) :
  Installation des Pakets ‘C:/Users/Jojo/AppData/Local/Temp/RtmpwbvsTn/file4308381719c3/NLMR_1.1.tar.gz’ hatte Exit-Status ungleich 0

Is there currently any way available to make it work? I already installed the newest versions of R, RStudio and Rtools. Thank you!

[mhesselbarth]

This looks like you don't have the GCC compiler installed. It seems like you are on Window OS? Try to download and install RTools first.

[JonathanGehret]

Thank you for the very quick reply! I have already newly installed RTools 4.2 earlier. I suppose I will try to reinstall it again and see if it works then.

Edit: Alright, because I installed RTools on a different drive I had to add it to PATH first so RStudio could find it. I added PATH="${RTOOLS42_HOME}\usr\bin;${PATH}" to a text file named .Renviron as described here: https://community.rstudio.com/t/installing-rtools-in-different-location-other-than-root-of-c/68698

Now it works, thanks a lot!

[srfall]

There is now probably also another problem https://cran.r-project.org/web/packages/RandomFields/index.html

RandomFields in not on cran anymore

[bitbacchus]

Ouuuuh, thanks for the note!

[maelle]

I came here to comment on RandomFields (as I saw the failure on https://ropensci.r-universe.dev/ui#builds). Any help needed?

[bitbacchus]

Hm, yes. Apparently the only way to install NLMR at the moment is to manually install RandomFields from GitHub first, i.e.:

devtools::install_github("cran/RandomFields")
devtools::install_github("ropensci/NLMR")

Shall we just wait for a while and see if RandomFields shows up on CRAN again?

[Milena3012]

Unfortunately I cannot get RandomFields to install either (ERROR: compilation failed for package ‘RandomFields’).

Is there another way to install RandomFields and NLMR?

[srfall]

Shall we just wait for a while and see if RandomFields shows up on CRAN again?

Just as an option: looks like RandomFields is only used in nlm_fbr & nlm_gaussianfield and there are two public implementations of these two algorithms in matblab: fbm & gaussianFields, which look like they would be relatively straight forward to port to R. And since the author already published another R package (truncatedNormal) one could maybe reach out to them and ask if they would be willing to contribute those to the package and thus remove the dependency from RandomFields.

[bitbacchus]

Unfortunately I cannot get RandomFields to install either (ERROR: compilation failed for package ‘RandomFields’).

This looks as if there is a compiler missing. For Windows, you'd need to install RTools (afaik) but for MacOS you probably need to do some brew install gfortran and/or brew install gcc or similar. Am I right, @mhesselbarth?

[bitbacchus]

Shall we just wait for a while and see if RandomFields shows up on CRAN again?

Just as an option: looks like RandomFields is only used in nlm_fbr & nlm_gaussianfield and there are two public implementations of these two algorithms in matblab: fbm & gaussianFields, which look like they would be relatively straight forward to port to R. And since the author already published another R package (truncatedNormal) one could maybe reach out to them and ask if they would be willing to contribute those to the package and thus remove the dependency from RandomFields.

Hmm, might be worth a look/try... Thanks @srfall

[mhesselbarth]

Am I right, @mhesselbarth?

On macOS, the easiest is to run xcode-select --install in the Terminal.app to install all compilers.

[achubaty]

It's official: RandomFields is no longer maintained.

Dear Users of RandomFields(Utils),

it is a de facto decision of CRAN that CRAN does not support any further updates of the auxiliary package RandomFieldsUtils since April 2022. So, I do not have any hope that a new version of RandomFields will be accepted by CRAN, eventually.

The future of my R packages is very unclear. The currently most likely scenario is to put the latest versions on github and to move to Julia for future programming.

Many thanks to you, Kurt and Uwe for the great support the past years.

Best, Martin

[bitbacchus]

Thanks for the info, @achubaty. I updated the installation section in the README.md, do people do know how to install NLMR until we solved the issue.

The problem with the idea of @srfall to port matlab code to R is that this will probably result in relatively slow code; the neat thing about RandomFields is that it is C++ code in its core. So we want to either find another fast implementation or implement it ourselves.

[mhesselbarth]

I am not that deep into the implementation of neither NLMR nor RandomFields, so I don't know where the issues with CRAN originate from, but could we just pull the specific source code we actually need from RandomFields and include it directly into NLMR?

[achubaty]

could we just pull the specific source code we actually need from RandomFields and include it directly into NLMR?

I don't think that will be very straightforward (and certainly not quick), especially since RandomFields also relied on RandomFieldsUtils. In the meantime, NLMR remains off CRAN which is blocking packages that depend on it.

Is it possible to quickly triage the 3(?) functions that relied on RandomFields to warn the user that they need RF+RFUtils installed (and possibly how to install from the CRAN archive at the very least). That way, the rest of the package is still usable.

Thanks!

[achubaty]

I updated the installation section in the README.md, do people do know how to install NLMR until we solved the issue.

@bitbacchus need to also install an archived version of RandomFieldUtils first or RF install will fail.

install.packages("https://cran.r-project.org/src/contrib/Archive/RandomFieldsUtils/RandomFieldsUtils_1.2.3.tar.gz", repos = NULL)
install.packages("https://cran.r-project.org/src/contrib/Archive/RandomFields/RandomFields_3.3.14.tar.gz", repos = NULL)

although note these are a huge pain to compile on Windows, so that leaves Windows users out of luck.

[achubaty]

digging into this further, it looks like RandomFieldsUtils is also a dependency of spatstat.random:

── Error (test_mosaicfield.R:4:1): (code run outside of `test_that()`) ─────────
Error: The package 'RandomFieldsUtils' is required
Backtrace:
    ▆
 1. └─NLMR::nlm_mosaicfield(...) at test_mosaicfield.R:4:0
 2.   └─spatstat.random::rLGCP(...)
 3.     └─spatstat.random (local) do.rLGCP(...)
 4.       └─spatstat.random::getRandomFieldsModelGen(model)
 5.         └─spatstat.random::kraeverRandomFields()
 6.           └─spatstat.random::kraever("RandomFieldsUtils")

That leaves the following functions that need to error conditionally based on whether RF/RFUtils are available:

• nlm_fbm
• nlm_gaussianfield
• nlm_mosaicfield

As a stop gap, you could provide RandomFields and RandomFieldsUtils in an r-universe repo and add that to Additional_repositories in the DESCRIPTION so that they can still be included as Suggested packages. I'm testing this in my fork (https://github.com/achubaty/NLMR) -- just waiting for the pkgs to be built in my r-universe repo.

[bitbacchus]

I updated the installation section in the README.md, do people do know how to install NLMR until we solved the issue.

@bitbacchus need to also install an archived version of RandomFieldUtils first or RF install will fail.

install.packages("https://cran.r-project.org/src/contrib/Archive/RandomFieldsUtils/RandomFieldsUtils_1.2.3.tar.gz", repos = NULL)
install.packages("https://cran.r-project.org/src/contrib/Archive/RandomFields/RandomFields_3.3.14.tar.gz", repos = NULL)

although note these are a huge pain to compile on Windows, so that leaves Windows users out of luck.

@achubaty thanks a bunch! Windows users "just" need RTools to compile packages, right? I'll paste a link to a how-to install RTools alongside.

[achubaty]

No, Rtools is not enough. Better to make those packages available in r-universe repo like I'm doing in my fork. I can do a PR now that things look like they are working properly.

[achubaty]

@bitbacchus please see PR #96

[mhesselbarth]

I am not 100% up-to-date with this, but given the PR #96, can we try to re-upload to CRAN?

[qiangxyz]

I successfully installed an old version of NLMR (NLMR_0.3.2) and it is running now. Any newer version failed in windows 11, even with rtools4.0. The flow:

1. install rtools 4.0
2. install.packages('RandomFieldsUtils')
3. install.packages('spatstat.core')
4. download RandomFields_3.1.50.zip from http://cran.nexr.com/web/packages/RandomFields/index.html and install it locally .
5. download NLMR_0.3.2 from https://cran.r-project.org/src/contrib/Archive/ and install it locally.

[achubaty]

It's unnecessary to install an old version. You can install directly from GitHub while the maintainers resubmit for CRAN.

Also, please note that the nexr CRAN mirror that's dominating Google search results is a very old snapshot of CRAN (no https!).

[qiangxyz]

Get it. I forgot about the PAT at the beginning, so the installation failed. Just found it. It's ok now. Thanks!

[mhesselbarth]

@marcosci as the maintainer needs to try to re-submit to CRAN, correct?

[achubaty]

@marcosci as the maintainer needs to try to re-submit to CRAN, correct?

Yes.

[marcosci]

Sorry, just had a look at this: Doesn't CRAN also enforces packages in Suggest to be on CRAN? If I send it to a CRAN server to be tested it complains about RandomFields again.

Anyhow ... is there a strict need that the package is on CRAN? I am actually quite annoyed by it and if it runs, works and is on GitHub ... 🤷

[mhesselbarth]

I just submitted a package with a Suggests which is not on CRAN as well. I did the same as here using Additional_repositories in the DESCRIPTION file and additionally an .onLoad() function (#103) to make sure the repo is available.

However, I do agree this is getting kind of annoying - I have no strong opinion about putting it on CRAN or not. There were just quite a few people asking about it.

[achubaty]

I have a few packages that suggest packages not on CRAN (including one that suggests NLMR ;) ). It's allowed as long as you point the user to getting them installed as needed: Use Additional_repostories in DESCRIPTION, and a message with instructions when they try using a function that needs the additional suggested package.

[maelle]

Hello! Just checking in on the status of this @marcosci @mhesselbarth (it's also fine if in the end you do not want to put it back on CRAN, no pressure from my side)

[maelle]

Hello! :smile_cat: Just checking again in on the status of this @marcosci @mhesselbarth (it's also fine if in the end you do not want to put it back on CRAN, no pressure from my side)

[mhesselbarth]

I would be happy trying to get it on CRAN again, but @marcosci is the maintainer who needs to submit etc

[bitbacchus]

I would be happy trying to get it on CRAN again, but @marcosci is the maintainer who needs to submit etc

We should maybe create a maintainer team with a shared e-mail. We do this with nlrx.

[maelle]

Ah cool that it works :shushing_face: , but for info in the CRAN repository policy it's stated https://cran.r-project.org/web/packages/policies.html

The package’s DESCRIPTION file must show both the name and email address of a single designated maintainer (a person, not a mailing list).

[mhesselbarth]

Given that nlrx is still on CRAN, they dont really seem to check that?

[marcosci]

Is there any benefit of the package being on CRAN? I still use it and just install it from Github. Not the biggest fan of CRAN anymore, don’t see the point of all the hassle for nonsense like solaris.On 6. May 2024, at 09:34, Maximilian Hesselbarth @.***> wrote: Given that nlrx is still on CRAN, they dont really seem to check that?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[bitbacchus]

Given that nlrx is still on CRAN, they dont really seem to check that?

we have this in de DESCRIPTION:

person("Sebastian", "Hanss", email = "nlrx@mailbox.org", 
                     role = c("cre"), comment = "Package maintainer together with Jan Salecker"))

And the e-mail address is a redirect to both of us.

[mhesselbarth]

I think the only advantage would be that it increases visibility and potential users by quite a bit. Many people don't know how to search and install packages from GitHub. But yeah...definitely discussable if that's worth all the effort.

[maelle]

Noting that people can also install packages from R-universe. (but it needs to be documented in the README)

[marcosci]

Package will not be available via CRAN anymore, as CRAN is medieval.

[mhesselbarth]

Hahahahah ⚔️