Re: [R-pkg-devel] [External] Re: Reference in the DESCRIPTION file

[Wang, Jifan]

Perfect, thank you!

From: Steven P Sanderson II 
Sent: Wednesday, July 19, 2023 4:19 PM
To: Wang, Jifan 
Cc: r-package-devel@r-project.org
Subject: [External] Re: [R-pkg-devel] Reference in the DESCRIPTION file

It should be, I have done this, I do not have a paper published for my packages 
so there is nothing to refer to for them. This can be the case for a great many 
packages.

On Wed, Jul 19, 2023 at 2:26 PM Wang, Jifan 
mailto:jifan.w...@tufts.edu>> wrote:
Hi all,
I was asked to add references describing the methods in my package. I plan to 
publish a paper describing this package and methods in details, but I wanted to 
refer the CRAN page in our paper. I have described the method briefly in the 
function documentation. I wonder what is the order of publishing a paper vs. 
submitting to CRAN. Is it fine to respond in the resubmission saying that we do 
not have the reference now but will add it later?

Thank you,
Jifan


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


--
Steven P Sanderson II, MPH
Book on Lulu
Personal Site

Caution: This message originated from outside of the Tufts University 
organization. Please exercise caution when clicking links or opening 
attachments. When in doubt, email the TTS Service Desk at 
i...@tufts.edu or call them directly at 617-627-3376.


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Reference in the DESCRIPTION file

[Steven P Sanderson II]

It should be, I have done this, I do not have a paper published for my
packages so there is nothing to refer to for them. This can be the case for
a great many packages.

On Wed, Jul 19, 2023 at 2:26 PM Wang, Jifan  wrote:

> Hi all,
> I was asked to add references describing the methods in my package. I plan
> to publish a paper describing this package and methods in details, but I
> wanted to refer the CRAN page in our paper. I have described the method
> briefly in the function documentation. I wonder what is the order of
> publishing a paper vs. submitting to CRAN. Is it fine to respond in the
> resubmission saying that we do not have the reference now but will add it
> later?
>
> Thank you,
> Jifan
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Steven P Sanderson II, MPH
Book on Lulu 
Personal Site 

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Package Load fails to find 3rd Party DLL

[Russell Almond]

Not sure if I reported the success here or not.

Copying the 3rd party DLL, but not the .lib file, to the src directory 
does work around the bug in the linker.


The complete working solution can be seen at 
https://github.com/ralmond/RNetica.


Thanks for the help.
--Russell


On 7/17/23 5:30 AM, Ivan Krylov wrote:

В Fri, 14 Jul 2023 22:25:51 +0300
Ivan Krylov  пишет:


Maybe it's a red herring. Maybe the message from nm about missing file
has always been harmless, and what we're seeing here is a bug in the
toolchain; perhaps ld.exe doesn't like something about Netica.lib so
much that it crashes. I think that's less likely. If you run the
commands manually but without mentioning NeticaDLL, do you get a DLL
in the end?


Judging by your build logs, this could be a toolchain bug. If you set
the *.lib file aside and only give the *.dll to the linker (using
-l:Netica.dll if necessary), does it still fail? I know that GCC can
link directly to *.dll files, without relying on import libraries.



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Reference in the DESCRIPTION file

[Wang, Jifan]

Hi all,
I was asked to add references describing the methods in my package. I plan to 
publish a paper describing this package and methods in details, but I wanted to 
refer the CRAN page in our paper. I have described the method briefly in the 
function documentation. I wonder what is the order of publishing a paper vs. 
submitting to CRAN. Is it fine to respond in the resubmission saying that we do 
not have the reference now but will add it later?

Thank you,
Jifan


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[Rd] _R_CHECK_DEPENDS_ONLY_ vs. packages in .Library [was: Check package without suggests]

[Ivan Krylov]

(Moving this one idea to R-devel)

В Wed, 19 Jul 2023 09:21:46 +0200
Henrik Bengtsson  пишет:

> If you're on macOS, and have installed R the default way, it takes
> more work to test on that platform. It works out of the box on Linux
> and MS Windows.  See the '[R-SIG-Mac] CRAN installer for macOS -
> directory permissions' thread started in April 2022
> ,
> continued in May 2022
> , and
> June 2022
> . It
> was then renamed to 'System-wide site library [Was: CRAN installer
> for macOS - directory permissions]' in June 2022
> .

Currently, a check with _R_CHECK_DEPENDS_ONLY_=TRUE assumes that
.Library only has base and recommended packages. This assumption can be
broken on macOS, and also on other operating systems when R is
installed into a writeable directory or is running without installation
(e.g. R-devel from an SVN checkout) and the user doesn't pre-create a
separate library.

What would be the downsides to implementing _R_CHECK_DEPENDS_ONLY_ the
same way that _R_CHECK_NO_RECOMMENDED_ is already implemented? The
latter works by creating fake packages (with a DESCRIPTION and an empty
file called "dummy_for_check" but nothing else in them) in a temporary
library that take precedence over the ones in .Library and fail loading.

-- 
Best regards,
Ivan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] Check package without suggests

[Henrik Bengtsson]

Hello,

this is *not* a new behavior on CRAN, at least on (re-)submissions to
CRAN.  The package has to pass R CMD check --as-cran with all OK. If
one of the Suggests:ed package is not installed, but one of your
examples or package tests needed it, that would be detected by the
check system.

The win-builder service is will detect this
(https://win-builder.r-project.org/).

See 

for an example how to do this on GitHub Actions.

If you're on macOS, and have installed R the default way, it takes
more work to test on that platform. It works out of the box on Linux
and MS Windows.  See the '[R-SIG-Mac] CRAN installer for macOS -
directory permissions' thread started in April 2022
,
continued in May 2022
, and
June 2022 .
It was then renamed to 'System-wide site library [Was: CRAN installer
for macOS - directory permissions]' in June 2022
.

/Henrik

On Tue, Jul 18, 2023 at 8:07 PM William Gearty  wrote:
>
> Hi John,
>
> You need to set the R CMD check environment variable
> _R_CHECK_FORCE_SUGGESTS_ to FALSE/0. You should be able to do this
> with the env_vars
> argument in rhub::check(). You can also achieve this with github actions by
> customizing your yaml file (example here:
> https://github.com/willgearty/deeptime/blob/master/.github/workflows/R-CMD-check.yaml#L57
> ).
>
> Best,
> Will
>
> --
> *William Gearty*
> *Lerner-Gray Postdoctoral Research Fellow*
> Division of Paleontology
> American Museum of Natural History
> williamgearty.com
>
>
>
> On Tue, Jul 18, 2023 at 10:38 AM John Harrold 
> wrote:
>
> > Howdy Folks,
> >
> > I recent had a package start failing because I wasn't checking properly in
> > my tests to make sure my suggested packages were installed before running
> > tests. I think this is something new running on CRAN where packages are
> > tested with only the packages specified as Imports in the DESCRIPTION file
> > are installed. It took me a bit of back and forth to get all of these
> > issues worked out.  I was wondering if anyone has a good way to run R CMD
> > check with only the imports installed?  A github action, or a
> > specific platform on rhub?
> >
> > Thank you,
> >
> > John
> > :wq
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[Rd] proposal for WRE: clarify that use of S4 classes implies use of superclasses

[Mikael Jagan]

If a package has

importClassesFrom(P, C)

in its NAMESPACE, then should it _also_ have

importClassesFrom(P, )
importClassesFrom(Q, )
## and so on

... ?  I think that WRE could be more clear on this point, and in any case
I _think_ that the answer is yes.

Notably, I think that this rule would resolve some of the problems
with stale caches that I described in this thread from September:

https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html

I've attached a script demonstrating my point.  It creates and installs a
package named TestPackage with

importClassesFrom(Matrix, dgCMatrix, CsparseMatrix)

in NAMESPACE and

setClass("whatever", contains = "dgCMatrix")

in R/*.R.  After installing the package, I see:


> ns <- asNamespace("TestPackage")
> names(ns)
 [1] ".__C__generalMatrix"  ".__C__Matrix" ".__C__sparseMatrix"
 [4] ".__C__compMatrix" ".__C__whatever"   "zzz"
 [7] ".packageName" ".__C__dsparseMatrix"  ".__NAMESPACE__."
[10] ".__C__dMatrix"".__S3MethodsTable__."
> sort(names(ns))
 [1] ".__C__Matrix" ".__C__compMatrix" ".__C__dMatrix"
 [4] ".__C__dsparseMatrix"  ".__C__generalMatrix"  ".__C__sparseMatrix"
 [7] ".__C__whatever"   ".__NAMESPACE__."  ".__S3MethodsTable__."
[10] ".packageName" "zzz"
> sort(names(parent.env(ns)))
[1] ".__C__CsparseMatrix" ".__C__dgCMatrix" "setClass"


i.e., the imported classes are cached in the parent of the namespace (the
imports environment), and superclasses of dgCMatrix that are _not_ imported
are cached in the namespace itself.  The caching of superclasses does _not_
occur if I add all of the superclasses to the importClassesFrom directive
in NAMESPACE _or_ if I delete the call to setClass in R/*.R.

It is precisely these cached superclasses that are liable to become stale,
because, if I understand correctly, the namespace is populated and serialized
at _install_ time, whereas the imports environment is populated at _load_ time.

Hence by clarifying in WRE that packages should import exported superclasses
of classes that they extend, etc., we could stem some of the "staleness" on
CRAN ...

But maybe my analysis is mistaken, so I'll wait for comments from others ...

Mikaelpackage <- "TestPackage"
dir.create(file.path(package, "R"), recursive = TRUE)

cat(file = file.path(package, "DESCRIPTION"), "
Package: TestPackage
Version: 0.0-0
License: GPL (>= 2)
Description: A (one paragraph) description of what
  the package does and why it may be useful.
Title: My First Collection of Functions
Author: First Last [aut, cre]
Maintainer: First Last 
Imports: Matrix, methods
")

cat(file = file.path(package, "NAMESPACE"), "
export(zzz)
importFrom(methods, setClass)
importClassesFrom(Matrix, dgCMatrix, CsparseMatrix)
")

cat(file = file.path(package, "R", paste0(package, ".R")), "
zzz <- function() double(3L)
#setClass(\"whatever\", contains = \"dgCMatrix\")
")

tools:::Rcmd(c("build", package))
tools:::Rcmd(c("INSTALL", Sys.glob(paste0(package, "_*.tar.gz"

## unlink(Sys.glob(paste0(package, "*")), recursive = TRUE)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel