Re: [Rd] Request: better default R_LIBS_USER

[Felipe Contreras]

On Thu, Mar 16, 2023 at 6:39 PM Dirk Eddelbuettel  wrote:
>
>
> On 16 March 2023 at 17:15, Henrik Bengtsson wrote:
> | We're all starting out with a fresh R_LIBS_USER once a year when a new
> | minor version of R is released,
>
> Maybe not "we all". I don't, and I know other Linux users who don't force a
> rebuild unless needed (as with R 3.6.* -> R 4.0.0).

Then you are not using the default.

And BTW, that's why the default location probably should be in a "4"
directory, not "4.2". And since it's even more unlikely that the
platform is going to change from one version to the next:

~/.local/share/R/4

Or something like that.

-- 
Felipe Contreras

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

Re: [Rd] det(diag(c(NaN, 1))) should be NaN, not 0

[Mikael Jagan]

Hmm ... I can no longer reproduce this under r83996 when configuring
--without-lapack and --without-blas {the default}.  Now det(A), det(B),
det(C), and det(D) are all NaN.

I assume that the reason is the recent update to use LAPACK 3.11.0?
But I don't see any related NEWS here:

https://netlib.org/lapack/lapack-3.11.0.html

It is possible that the underlying issue in DGETRF (INFO>0 due to NaN
pivots rather than 0 pivots {=> singular}) still exists for matrices
less trivial than my 2-by-2 examples.  Will have to experiment ...

Mikael

On 2022-11-09 3:58 pm, Mikael Jagan wrote:

Hello,

Currently, determinant(A) calculates the determinant of 'A' by factorizing
A=LU and computing prod(diag(U)) [or the logarithm of the absolute value].
The factorization is done by LAPACK routine DGETRF, which gives a status
code INFO, documented [1] as follows:

*>  INFO is INTEGER
*>  = 0:  successful exit
*>  < 0:  if INFO = -i, the i-th argument had an illegal value
*>  > 0:  if INFO = i, U(i,i) is exactly zero. The factorization
*>has been completed, but the factor U is exactly
*>singular, and division by zero will occur if it is used
*>to solve a system of equations.

Accordingly, when INF0>0, determinant(A) behaves as det(A)=0, _not_ computing
prod(diag(U)).  The problem here is that DGETRF can _also_ give positive
INFO for matrices containing NaN, which may very well not be singular for some
finite value of NaN.

I claim that, when INFO>0, determinant(A) should _not_ behave as det(A)=0
unconditionally, but rather sometimes (depending on some test) give NaN.
Here is one case where 0 is really "wrong":

  > (A <- diag(c(NaN, 1)))
   [,1] [,2]
[1,]  NaN0
[2,]01
  > det(A)
[1] 0

R isn't consistent, either:

  > (B <- diag(c(1, NaN)))
   [,1] [,2]
[1,]10
[2,]0  NaN
  > det(B)
[1] NaN

Here, DGETRF _does_ succeed, because it does not "see" the trailing NaN in 'B'.

So: Should R change to better handle the INFO>0 case?  If so, how?

Ideally (I think), the proposed change would give NaN for 'A' and 'B'
above and 0 for 'C' and 'D' below (both of which really _are_ singular):

  > (C <- matrix(c(NaN, NaN, 0, 0), 2L, 2L))
   [,1] [,2]
[1,]  NaN0
[2,]  NaN0
  > det(C)
[1] NaN
  > (D <- t(C))
   [,1] [,2]
[1,]  NaN  NaN
[2,]00
  > det(D)
[1] 0

Furthermore, the proposed change should _not_ decrease the performance
of determinant(A) for nonsingular 'A' ...

For those looking, the relevant C-level function is det_ge_real(),
defined in R-devel/src/modules/lapack/Lapack.c (at line 1260 in r83320).

Mikael

[1] https://github.com/Reference-LAPACK/lapack/blob/master/SRC/dgetrf.f


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

Re: [Rd] Request: better default R_LIBS_USER

[Felipe Contreras]

On Thu, Mar 16, 2023 at 4:08 PM Dirk Eddelbuettel  wrote:
>
>
> On 16 March 2023 at 13:39, Felipe Contreras wrote:
> | I see R by default installs packages in ~/R. I know I can change the
> | default directory with R_LIBS_USER, but software shouldn't be
> | polluting the home directory.
> |
> | For example both python and node install packages to ~/.local/lib,
> | ruby to ~/.local/share. They don't install to for example ~/node.
> |
> | R should do the same: it should install packages to somewhere inside
> | ~/.local by default.
>
> Use of ~/.local is a fairly recent convention (relative to the time R has
> been around, which is now decades) and one which R supports already eg in the
> (rather useful) portable config directories:
>
>> tools::R_user_dir("r2u")
>[1] "/home/edd/.local/share/R/r2u"
>>
>
> Your best bet really to govern your .libPaths from your Rprofile.site and
> Renviron.site

I already have fixed it for myself, my request was about the default,
so most users don't have to fix it for themselves too.

> rather than asking a few million R users to adjust from past
> practice.

Why would they have to adjust anything?

Just expand %U to both:

paste(c(
file.path(home, ".local", "lib", "r", x.y),
file.path(home, "R", paste0(R.version$platform, "-library"), x.y)
), collapse = ":")

Then R would install packages to the new location in new installations
by default, but still use packages from the old location if present.

Moreover, this location is going to change the next time the minor
version is bumped anyway.

Cheers.

-- 
Felipe Contreras

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

Re: [Rd] Request: better default R_LIBS_USER

[Dirk Eddelbuettel]

On 16 March 2023 at 17:15, Henrik Bengtsson wrote:
| We're all starting out with a fresh R_LIBS_USER once a year when a new
| minor version of R is released,

Maybe not "we all". I don't, and I know other Linux users who don't force a
rebuild unless needed (as with R 3.6.* -> R 4.0.0).

R signals clearly when a rebuild is needed at a major version change, and we
had this (if I recall correctly) about twice in the six or so years.  I carry
my directories over with ease from most (major) release to the next: By doing
nothing as my .libPaths has no version number in.

[ In fairness the last few upgrades were semi-dirtied because package needing
a graphics device needed a rebuild as the tireless Paul Murrell extends
capabilities and hence API interfaces. But that affects usually half a dozen
out of maybe hundreds of installed packages. ]

[ But your post was helpful in adding how to define a version, or arch, or
... handle for which `help(".Library")` has all the relevant details. ]

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] Request: better default R_LIBS_USER

[Henrik Bengtsson]

> Your best bet really to govern your .libPaths from your Rprofile.site and
Renviron.site ...

To do this for any version of R, one can add:

R_LIBS_USER=~/.local/share/R/%p-library/%v

to ~/.Renviron or the Renviron.site file. This automatically expands
to the platform and R x.y version early on when R starts up, e.g.
~/.local/share/R/x86_64-pc-linux-gnu-library/4.2.

> rather than asking a few million R users to adjust from past practice.

We're all starting out with a fresh R_LIBS_USER once a year when a new
minor version of R is released, so changing the default should be
doable without major troubles. On MS Windows, this move has already
been made. When R 4.2.0 was released, the default R_LIBS_USER location
on MS Windows was changed, similarly, to the Local Application Data
directory in R (>= 4.2.0), e.g.
C:\Users\alice\AppData\Local\R\win-library\4.2.

/Henrik

On Thu, Mar 16, 2023 at 3:09 PM Dirk Eddelbuettel  wrote:
>
>
> On 16 March 2023 at 13:39, Felipe Contreras wrote:
> | I see R by default installs packages in ~/R. I know I can change the
> | default directory with R_LIBS_USER, but software shouldn't be
> | polluting the home directory.
> |
> | For example both python and node install packages to ~/.local/lib,
> | ruby to ~/.local/share. They don't install to for example ~/node.
> |
> | R should do the same: it should install packages to somewhere inside
> | ~/.local by default.
>
> Use of ~/.local is a fairly recent convention (relative to the time R has
> been around, which is now decades) and one which R supports already eg in the
> (rather useful) portable config directories:
>
>> tools::R_user_dir("r2u")
>[1] "/home/edd/.local/share/R/r2u"
>>
>
> Your best bet really to govern your .libPaths from your Rprofile.site and
> Renviron.site rather than asking a few million R users to adjust from past
> practice.
>
> Also: personal preferences differ. I think of Linux as multi-tenant and
> expect other (even system) users to have access to packages I install. So I
> am happy with this default --- which goes after all back to fruitful
> discussion in a bar in Vienna with Kurt and Fritz some 20 years ago:
>
>> .libPaths()
>[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
>[3] "/usr/lib/R/library"
>>
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Request: better default R_LIBS_USER

[Dirk Eddelbuettel]

On 16 March 2023 at 13:39, Felipe Contreras wrote:
| I see R by default installs packages in ~/R. I know I can change the
| default directory with R_LIBS_USER, but software shouldn't be
| polluting the home directory.
| 
| For example both python and node install packages to ~/.local/lib,
| ruby to ~/.local/share. They don't install to for example ~/node.
| 
| R should do the same: it should install packages to somewhere inside
| ~/.local by default.

Use of ~/.local is a fairly recent convention (relative to the time R has
been around, which is now decades) and one which R supports already eg in the
(rather useful) portable config directories:

   > tools::R_user_dir("r2u")
   [1] "/home/edd/.local/share/R/r2u"
   > 

Your best bet really to govern your .libPaths from your Rprofile.site and
Renviron.site rather than asking a few million R users to adjust from past
practice.

Also: personal preferences differ. I think of Linux as multi-tenant and
expect other (even system) users to have access to packages I install. So I
am happy with this default --- which goes after all back to fruitful
discussion in a bar in Vienna with Kurt and Fritz some 20 years ago:

   > .libPaths()
   [1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
   [3] "/usr/lib/R/library"   
   > 

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

[Rd] Request: better default R_LIBS_USER

[Felipe Contreras]

Hi,

I see R by default installs packages in ~/R. I know I can change the
default directory with R_LIBS_USER, but software shouldn't be
polluting the home directory.

For example both python and node install packages to ~/.local/lib,
ruby to ~/.local/share. They don't install to for example ~/node.

R should do the same: it should install packages to somewhere inside
~/.local by default.

Cheers.

-- 
Felipe Contreras

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

Re: [R-pkg-devel] Should 'methods' be in Imports?

[Noah Greifer]

Thank you both for your responses. Based on Ivan's dig into the comments,
it seems there is ambiguity, even by the CRAN team. Still, it looks like it
would be preferable to (and would not cause any harm to) include the base
packages in DESCRIPTION if they are used at all in a package, whether by ::
or imported from in the Namespace. I'll update my packages accordingly.

Noah

[[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] How to declare Bioconductor Dependencies in the Description File of my R Package

[Martin Morgan]

I would not follow the instructions in RTIGER�s README for installing 
Bioconductor packages.

BiocManager::install(�RTIGER�) would install both CRAN and Bioconductor 
dependencies of RTIGER, and would be my preferred instruction in a README or 
INSTALL file. A complete instruction might be to install your package as if it 
were on Bioconductor �

If (!requireNamepace(�BiocManager�, quietly = TRUE))
install.packages(�BiocManager�)
BiocManager::install(��)

It does not make sense to me to have instructions in .onAttach / .onLoad or in 
each function for the user to install a �Suggests:� package, when actually the 
package is required for use and belongs in Imports: or perhaps Depends:.

The instruction to use �version = �3.14�� of Bioconductor in the RTIGER 
document is not universally correct, since different Bioconductor versions are 
tied to specific R versions (see 
https://bioconductor.org/about/release-announcements/ ). On one version of R I 
am currently using, I get

> BiocManager::install(version = "3.14")
Error: Bioconductor version '3.14' requires R version '4.1'; use
  `BiocManager::install(version = '3.17')` with R version 4.3; see
  https://bioconductor.org/install

The instruction to install a vector of Bioconductor packages is also 
unnecessary for Bioconductor packages in the Imports: or Depends: field of 
, or if one were to pass the argument `dependencies = TRUE` to 
either BiocManager::install() or install.packages() (to get the Suggests: 
packages of  to be installed, as well as Depends:, Imports: and 
LinkingTo:).

Briefly, installation requires R to know the correct repositories. The command

BiocManager::repositories()

Returns a vector of Bioconductor and CRAN repositories relevant to your version 
of R. If one is averse to using BiocManager::install(�RTIGER�), a reasonable 
alternative, though still requiring that the BiocManager package is installed, 
is

install.packages(�RTIGER�, repos = BiocManager::repositories())

Base R also provides a mechanism for specifying Bioconductor repositories, via 
`setRepositories()` called before install.packages(). However, this is not 
recommended because, as can be seen on the web page mentioned above, there are 
two versions of Bioconductor for each version of R � one always gets the �old� 
Bioconductor version, even when a newer version is available.

From: R-package-devel  on behalf of Ivan 
Krylov 
Date: Thursday, March 16, 2023 at 2:15 PM
To: Ruff, Sergej 
Cc: r-package-devel@r-project.org 
Subject: Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the 
Description File of my R Package
On Thu, 16 Mar 2023 17:01:55 +
"Ruff, Sergej"  wrote:

> Last question: How does CRAN work with Bioconductor Dependencies?
> Will CRAN accept limma as a dependency or will my submission be
> rejected?

It's not explicitly spelled out in the CRAN policy
, but
Bioconductor and CRAN are the "mainstream repositories" for the
purposes of the following rule:

>> Packages on which a CRAN package depends should be available from a
>> mainstream repository

(Even non-mainstream repositories are allowed for optional dependencies
if you follow a few additional rules.)

Here's an example of a CRAN package with a strong dependency on a
Bioconductor package: . You
can see the extra instructions for installing the Bioconductor
dependencies in its README.

--
Best regards,
Ivan

__
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

Re: [R-pkg-devel] Should 'methods' be in Imports?

[Ivan Krylov]

On Thu, 16 Mar 2023 11:29:33 -0400
Noah Greifer  wrote:

> Is including these packages filling the DESCRIPTION with unnecessary
> dependencies that are automatically satisfied, or is it being
> helpfully explicit about the packages your package relies on?

Here's a comment from the part of R CMD check that checks for NAMESPACE
dependencies unstated in DESCRIPTION:

>> Not clear whether we want to require *all* namespace package
>> dependencies listed in DESCRIPTION, or e.g. just the ones on
>> non-base packages.  Do the latter for time being ...
>> Actually we need to know at least about S4-using packages,
>> since we need to reinstall if those change.

So the answer is maybe. Personally, I opt for listing even the base
packages explicitly, but it's a choice. Duncan's quote from WRE hints
that this may be enforced in the future.

I do find it a bit strange that not listing methods as a dependency in
DESCRIPTION doesn't lead to complaints from R CMD check, because it
does seem that the code excludes methods (and stats4) from the list of
packages that are currently okay not to declare in DESCRIPTION.

-- 
Best regards,
Ivan

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

Re: [Rd] Making headers self-contained for static analysis

[Marc Schwartz via R-devel]

Hi,

There are a limited number of MIME file types that are accepted through the 
list server, with plain text being one. Even though a patch file should be 
plain text, it is possible that your mail client may not have set the correct 
MIME type for your patch file attachment. If so, that would explain why it was 
filtered from the list.

For future reference, if you change the file extension to ".txt" and then 
attach it, that should get picked up as plain text and get through the list 
server filters.

Regards,

Marc Schwartz
R-Devel Co-Admin


On March 16, 2023 at 2:32:39 PM, Lionel Henry via R-devel 
(r-devel@r-project.org (mailto:r-devel@r-project.org)) wrote:

> People have let me know that the attachment didn't make it through.
> Do patches get filtered out?
>
> Please find it there:
> https://github.com/lionel-/r-svn/commit/e3de56798b1321a3fa8688a42bbb73d763b78024.patch
>
> I'm also happy to post it on the bugzilla if that makes sense.
>
> Best,
> Lionel
>
> On 3/16/23, Lionel Henry wrote:
> > Hello,
> >
> > I started using clangd to get better static analysis and code
> > refactoring tooling with the R sources (using eglot-mode in Emacs, it
> > just works once you've generated a `compile_commands.json` file with
> > `bear make all`). I noticed that the static analyser can't understand
> > several header files because these are not self-contained. So I went
> > through all .h files and inserted the missing includes, cf the
> > attached patch.
> >
> > Making the headers self-contained has consequences for the .c or .cpp
> > files that include them. In the case of C files, the only downside I
> > see is that it might cause users to accidentally rely on indirect
> > inclusion of standard headers, instead of directly including the
> > header to make the dependency explicit as would be good practice.
> > This doesn't seem like a big deal compared to the benefits of enabling
> > static analysis.
> >
> > However in the case of C++ that's more problematic. We don't want to
> > include the C headers because that would pollute the global namespace
> > and users might prefer to import the missing symbols (`size_t` and
> > `FILE`) selectively. Also that wouldn't help static analysis within
> > the header files since the analysers use the C path. So I have guarded
> > inclusion of standard C headers behing a `__cplusplus` check.
> >
> > If that makes sense, would R core consider applying the attached patch
> > to the R sources?
> >
> > Best,
> > Lionel
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [R-pkg-devel] Should 'methods' be in Imports?

[Duncan Murdoch]

On 16/03/2023 2:21 p.m., Noah Greifer wrote:


Thank you for your input. /broom/, /mlogit/, /twang/, and /Hmisc/ 
are examples of major packages that import functions from /stats/, 
/utils/, /graphics/, or other base packages but don't include them in 
the DESCRIPTION. All of my packages (/cobalt/, /WeightIt/, /MatchIt/) do 
too, and I have never had a message from CRAN about it. (None of these 
are specifically about /methods/, but as a base package I assume it 
should work the same as these others.)




broom doesn't mention stats in DESCRIPTION, but does import from it in 
the NAMESPACE. (I haven't checked the rest of your list.)  I'm a little 
surprised by that, but it's understandable:  the NAMESPACE does declare 
that stats is needed.  WRE says this about Imports:


"Namespaces accessed by the ‘::’ and ‘:::’ operators must be listed 
here, or in ‘Suggests’ or ‘Enhances’ (see below). Ideally this field 
will include all the standard packages that are used, and it is 
important to include S4-using packages."


So the use of Imports for "standard packages" that are used in NAMESPACE 
appears to be optional but recommended.


However, my understanding was that you were talking about using things 
like graphics::abline without importing any graphics functions via the 
NAMESPACE; in that case, the manual is very explicit that you would need 
to put graphics in Imports.  That doesn't mean "R CMD check" will 
complain if you don't, but it does mean that it might start doing so if 
it doesn't already.


Do you know of any examples of packages that use things like 
graphics::abline without mentioning graphics in either the NAMESPACE or 
DESCRIPTION file?


Duncan Murdoch

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

Re: [Rd] Making headers self-contained for static analysis

[Lionel Henry via R-devel]

People have let me know that the attachment didn't make it through.
Do patches get filtered out?

Please find it there:
https://github.com/lionel-/r-svn/commit/e3de56798b1321a3fa8688a42bbb73d763b78024.patch

I'm also happy to post it on the bugzilla if that makes sense.

Best,
Lionel

On 3/16/23, Lionel Henry  wrote:
> Hello,
>
> I started using clangd to get better static analysis and code
> refactoring tooling with the R sources (using eglot-mode in Emacs, it
> just works once you've generated a `compile_commands.json` file with
> `bear make all`). I noticed that the static analyser can't understand
> several header files because these are not self-contained. So I went
> through all .h files and inserted the missing includes, cf the
> attached patch.
>
> Making the headers self-contained has consequences for the .c or .cpp
> files that include them. In the case of C files, the only downside I
> see is that it might cause users to accidentally rely on indirect
> inclusion of standard headers, instead of directly including the
> header to make the dependency explicit as would be good practice.
> This doesn't seem like a big deal compared to the benefits of enabling
> static analysis.
>
> However in the case of C++ that's more problematic. We don't want to
> include the C headers because that would pollute the global namespace
> and users might prefer to import the missing symbols (`size_t` and
> `FILE`) selectively. Also that wouldn't help static analysis within
> the header files since the analysers use the C path. So I have guarded
> inclusion of standard C headers behing a `__cplusplus` check.
>
> If that makes sense, would R core consider applying the attached patch
> to the R sources?
>
> Best,
> Lionel
>

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

Re: [Rd] Making headers self-contained for static analysis

[Ivan Krylov]

Hello Lionel,

Just letting you know off-list that the patch didn't make it through.
Unfortunately, I don't remember the exact rules regarding attachments
(does text/plain work?), but an external link is always an option,
especially for large patches.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Should 'methods' be in Imports?

[Noah Greifer]

Thank you for your input. *broom*, *mlogit*, *twang*, and *Hmisc*
are examples of major packages that import functions from *stats*, *utils*,
*graphics*, or other base packages but don't include them in the
DESCRIPTION. All of my packages (*cobalt*, *WeightIt*, *MatchIt*) do too,
and I have never had a message from CRAN about it. (None of these are
specifically about *methods*, but as a base package I assume it should work
the same as these others.)

Noah

[[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] How to declare Bioconductor Dependencies in the Description File of my R Package

[Ivan Krylov]

On Thu, 16 Mar 2023 17:01:55 +
"Ruff, Sergej"  wrote:

> Last question: How does CRAN work with Bioconductor Dependencies?
> Will CRAN accept limma as a dependency or will my submission be
> rejected?

It's not explicitly spelled out in the CRAN policy
, but
Bioconductor and CRAN are the "mainstream repositories" for the
purposes of the following rule:

>> Packages on which a CRAN package depends should be available from a
>> mainstream repository

(Even non-mainstream repositories are allowed for optional dependencies
if you follow a few additional rules.)

Here's an example of a CRAN package with a strong dependency on a
Bioconductor package: . You
can see the extra instructions for installing the Bioconductor
dependencies in its README.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

[Tiago Olivoto]

Thanks Duncan,
I'm in the way of a new CRAN submission and I will make sure to call
check_ebi() in the body of each function. This should ensure that the check
for EBImage will be called even with pliman::object_edge( ... ), for
example.

Best regards,
Olivoto

Em qui., 16 de mar. de 2023 às 14:15, Duncan Murdoch <
murdoch.dun...@gmail.com> escreveu:

> On 16/03/2023 12:36 p.m., Tiago Olivoto wrote:
> > Hi,
> > My package pliman depends on EBImage which is in Bioconductor. I have
> > created a function check_ebi() <
> >
> https://github.com/TiagoOlivoto/pliman/blob/e6efc4b6a2396600939e308c235aeb9ab47af375/R/utilities.R#L534
> >
> > that is called in .onAttach() <
> > https://github.com/TiagoOlivoto/pliman/blob/master/R/zzz.R#L36>  and
> checks
> > if EBImage is installed. If not, the function asks the user to install
> it.
>
> If some other package loads but doesn't attach pliman, and is missing
> EBImage, does it fail gracefully?  That's also important.  I'd test what
> happens if a user runs pliman::object_edge( ... ) .  (That function
> isn't in the CRAN version, just the Github version, so I haven't tried
> this.)
>
> Duncan Murdoch
>
>
> > Both EBImage and BiocManager are listed as suggests <
> > https://github.com/TiagoOlivoto/pliman/blob/master/DESCRIPTION#L22>
> >
> > I believe that this could be a possible solution
> > Best regards,
> > Olivoto
> >
> >
> > Em qui., 16 de mar. de 2023 às 11:18, Ruff, Sergej <
> > sergej.r...@tiho-hannover.de> escreveu:
> >
> >> I am currently building a package which uses the "limma"-package as a
> >> dependency.
> >>
> >> I want to submit my package to CRAN.
> >>
> >> Do I need to declare Bioconductor-dependencies such as Limma differently
> >> in the Description-File of my Package?
> >>
> >> The Check-Function in R shows no Notes, Warnings or Errors, but I am not
> >> sure if that means that limma will install when installing my package
> from
> >> CRAN.
> >>
> >> Currently I am declaring limma like this:
> >>
> >> Suggests:
> >>
> >>  limma
> >>
> >>
> >>
> >> Can CRAN identify that limma is a Bioconductor-Package and will it Limma
> >> install, when installing my package from CRAN?
> >>
> >>  [[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
>
>

[[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] How to declare Bioconductor Dependencies in the Description File of my R Package

[Tiago Olivoto]

Hi Sergej,

I sincerely don't know if the position of biocView really matters (I'll try
it when preparing for the new CRAN release of pliman). I believe that
biocView will not allow you to put limma in the imports field and
automatically install it from Bioconductor, as you can see here in this
discussion <
https://stackoverflow.com/questions/54411495/bioconductor-packages-not-installing-with-biocviews-specification-in-description
>

In my case, I had no errors when submitting pliman to CRAN using EBImage as
suggests (I haven't yet tried to use biocView: and EBImage in the Imports
section).

Best regards,
Olivoto

Em qui., 16 de mar. de 2023 às 14:01, Ruff, Sergej <
sergej.r...@tiho-hannover.de> escreveu:

> thank you.
>
>
> I see you added biocView: below your suggested Dependencies. Is it
> necessary for CRAN to identify Bioconductor Dependencies and if so, should
> I add it below or above the suggested packages? Do I also need BiocManager
> among my Suggests?
>
>
> Last question: How does CRAN work with Bioconductor Dependencies? Will
> CRAN accept limma as a dependency or will my submission be rejected?
>
>
> Best regards,
>
> Sergej
> --
> *Von:* Tiago Olivoto 
> *Gesendet:* Donnerstag, 16. März 2023 17:36:47
> *An:* Ruff, Sergej
> *Cc:* r-package-devel@r-project.org
> *Betreff:* Re: [R-pkg-devel] How to declare Bioconductor Dependencies in
> the Description File of my R Package
>
> Hi,
> My package pliman depends on EBImage which is in Bioconductor. I have
> created a function check_ebi() <
> https://github.com/TiagoOlivoto/pliman/blob/e6efc4b6a2396600939e308c235aeb9ab47af375/R/utilities.R#L534>
> that is called in .onAttach() <
> https://github.com/TiagoOlivoto/pliman/blob/master/R/zzz.R#L36>  and
> checks if EBImage is installed. If not, the function asks the user to
> install it. Both EBImage and BiocManager are listed as suggests <
> https://github.com/TiagoOlivoto/pliman/blob/master/DESCRIPTION#L22>
>
> I believe that this could be a possible solution
> Best regards,
> Olivoto
>
>
> Em qui., 16 de mar. de 2023 às 11:18, Ruff, Sergej <
> sergej.r...@tiho-hannover.de> escreveu:
>
>> I am currently building a package which uses the "limma"-package as a
>> dependency.
>>
>> I want to submit my package to CRAN.
>>
>> Do I need to declare Bioconductor-dependencies such as Limma differently
>> in the Description-File of my Package?
>>
>> The Check-Function in R shows no Notes, Warnings or Errors, but I am not
>> sure if that means that limma will install when installing my package from
>> CRAN.
>>
>> Currently I am declaring limma like this:
>>
>> Suggests:
>>
>> limma
>>
>>
>>
>> Can CRAN identify that limma is a Bioconductor-Package and will it Limma
>> install, when installing my package from CRAN?
>>
>> [[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

Re: [Rd] isNamespaceLoaded() while the namespace is loading

[Lionel Henry via R-devel]

Hello,

We've run into this issue multiple times and it's often a head
scratcher when it happens. We are using workarounds but it would be
great to fix this for R 4.3. Would an R core member have time to
review the patch that we supplied in
https://bugs.r-project.org/show_bug.cgi?id=18489 ?

Best,
Lionel


On 1/21/22, Gábor Csárdi  wrote:
> We ran into a bug in our package that seems to boil down to
> isNamespaceLoaded() returning TRUE for namespaces that R is currently
> loading.
>
> We had something like this in an .onLoad function:
>
> if (isNamespaceLoaded("upstream")) {
>   upstream::upstream_function()
> }
>
> Which seems OK, unless upstream (recursively) imports the package
> having this code. Should that happen, the loading of upstream triggers
> the loading of this package as well and isNamespaceLoaded() seems to
> return TRUE, even though the namespace of upstream is not fully loaded
> yet, and we get an error that looks like this:
>
> Error : .onLoad failed in loadNamespace() for 'foo', details:
>  call: NULL
>  error: 'upstream_function' is not an exported object from
> 'namespace:upstream'
>
> I wonder if isNamespaceLoaded() returning TRUE is correct in this
> case, or returning FALSE would be better. Or maybe it would make sense
> to have a way to query the packages that are being loaded currently?
>
> AFAICT this works, but it does use some implementation details from
> loadNamespace(), so it does not seem like a proper solution:
>
> dynGet("__NameSpacesLoading__", NULL)
>
> Another workaround is something like this:
>
>   is_loaded <- function(pkg) {
> if (!isNamespaceLoaded(pkg)) return(FALSE)
> tryCatch({
>   loadNamespace(pkg)
>   TRUE
> }, error = function(err) FALSE)
>   }
>
> which forces an error for currently loading namespaces by triggering a
> (fake) recursive dependency.
>
> Thanks,
> Gabor
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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

[Rd] Making headers self-contained for static analysis

[Lionel Henry via R-devel]

Hello,

I started using clangd to get better static analysis and code
refactoring tooling with the R sources (using eglot-mode in Emacs, it
just works once you've generated a `compile_commands.json` file with
`bear make all`). I noticed that the static analyser can't understand
several header files because these are not self-contained. So I went
through all .h files and inserted the missing includes, cf the
attached patch.

Making the headers self-contained has consequences for the .c or .cpp
files that include them. In the case of C files, the only downside I
see is that it might cause users to accidentally rely on indirect
inclusion of standard headers, instead of directly including the
header to make the dependency explicit as would be good practice.
This doesn't seem like a big deal compared to the benefits of enabling
static analysis.

However in the case of C++ that's more problematic. We don't want to
include the C headers because that would pollute the global namespace
and users might prefer to import the missing symbols (`size_t` and
`FILE`) selectively. Also that wouldn't help static analysis within
the header files since the analysers use the C path. So I have guarded
inclusion of standard C headers behing a `__cplusplus` check.

If that makes sense, would R core consider applying the attached patch
to the R sources?

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

Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

[Duncan Murdoch]

On 16/03/2023 12:36 p.m., Tiago Olivoto wrote:

Hi,
My package pliman depends on EBImage which is in Bioconductor. I have
created a function check_ebi() <
https://github.com/TiagoOlivoto/pliman/blob/e6efc4b6a2396600939e308c235aeb9ab47af375/R/utilities.R#L534>
that is called in .onAttach() <
https://github.com/TiagoOlivoto/pliman/blob/master/R/zzz.R#L36>  and checks
if EBImage is installed. If not, the function asks the user to install it.


If some other package loads but doesn't attach pliman, and is missing 
EBImage, does it fail gracefully?  That's also important.  I'd test what 
happens if a user runs pliman::object_edge( ... ) .  (That function 
isn't in the CRAN version, just the Github version, so I haven't tried 
this.)


Duncan Murdoch



Both EBImage and BiocManager are listed as suggests <
https://github.com/TiagoOlivoto/pliman/blob/master/DESCRIPTION#L22>

I believe that this could be a possible solution
Best regards,
Olivoto


Em qui., 16 de mar. de 2023 às 11:18, Ruff, Sergej <
sergej.r...@tiho-hannover.de> escreveu:


I am currently building a package which uses the "limma"-package as a
dependency.

I want to submit my package to CRAN.

Do I need to declare Bioconductor-dependencies such as Limma differently
in the Description-File of my Package?

The Check-Function in R shows no Notes, Warnings or Errors, but I am not
sure if that means that limma will install when installing my package from
CRAN.

Currently I am declaring limma like this:

Suggests:

 limma



Can CRAN identify that limma is a Bioconductor-Package and will it Limma
install, when installing my package from CRAN?

 [[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

Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

[Ruff, Sergej]

thank you.


I see you added biocView: below your suggested Dependencies. Is it necessary 
for CRAN to identify Bioconductor Dependencies and if so, should I add it below 
or above the suggested packages? Do I also need BiocManager among my Suggests?


Last question: How does CRAN work with Bioconductor Dependencies? Will CRAN 
accept limma as a dependency or will my submission be rejected?


Best regards,

Sergej


Von: Tiago Olivoto 
Gesendet: Donnerstag, 16. M�rz 2023 17:36:47
An: Ruff, Sergej
Cc: r-package-devel@r-project.org
Betreff: Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the 
Description File of my R Package

Hi,
My package pliman depends on EBImage which is in Bioconductor. I have created a 
function check_ebi() 

 that is called in .onAttach() 
  and checks if 
EBImage is installed. If not, the function asks the user to install it. Both 
EBImage and BiocManager are listed as suggests 


I believe that this could be a possible solution
Best regards,
Olivoto


Em qui., 16 de mar. de 2023 �s 11:18, Ruff, Sergej 
mailto:sergej.r...@tiho-hannover.de>> escreveu:
I am currently building a package which uses the "limma"-package as a 
dependency.

I want to submit my package to CRAN.

Do I need to declare Bioconductor-dependencies such as Limma differently in the 
Description-File of my Package?

The Check-Function in R shows no Notes, Warnings or Errors, but I am not sure 
if that means that limma will install when installing my package from CRAN.

Currently I am declaring limma like this:

Suggests:

limma



Can CRAN identify that limma is a Bioconductor-Package and will it Limma 
install, when installing my package from CRAN?

[[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

Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

[Tiago Olivoto]

Hi,
My package pliman depends on EBImage which is in Bioconductor. I have
created a function check_ebi() <
https://github.com/TiagoOlivoto/pliman/blob/e6efc4b6a2396600939e308c235aeb9ab47af375/R/utilities.R#L534>
that is called in .onAttach() <
https://github.com/TiagoOlivoto/pliman/blob/master/R/zzz.R#L36>  and checks
if EBImage is installed. If not, the function asks the user to install it.
Both EBImage and BiocManager are listed as suggests <
https://github.com/TiagoOlivoto/pliman/blob/master/DESCRIPTION#L22>

I believe that this could be a possible solution
Best regards,
Olivoto


Em qui., 16 de mar. de 2023 às 11:18, Ruff, Sergej <
sergej.r...@tiho-hannover.de> escreveu:

> I am currently building a package which uses the "limma"-package as a
> dependency.
>
> I want to submit my package to CRAN.
>
> Do I need to declare Bioconductor-dependencies such as Limma differently
> in the Description-File of my Package?
>
> The Check-Function in R shows no Notes, Warnings or Errors, but I am not
> sure if that means that limma will install when installing my package from
> CRAN.
>
> Currently I am declaring limma like this:
>
> Suggests:
>
> limma
>
>
>
> Can CRAN identify that limma is a Bioconductor-Package and will it Limma
> install, when installing my package from CRAN?
>
> [[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

Re: [R-pkg-devel] Should 'methods' be in Imports?

[Duncan Murdoch]

I think the Writing R Extensions manual is pretty clear about this: 
yes, you should include "methods" in Imports or Depends if you are 
calling methods::.


You say "some packages do so and some don't".  Which ones don't?  It's 
helpful to be specific in your examples.


Duncan Murdoch

On 16/03/2023 11:29 a.m., Noah Greifer wrote:

Hello developers,

I am wondering if base packages whose functions are used in my package need
to be present in Imports in my DESCRIPTION. For example, if I use the
function abline(), which exists in the *graphics* package, do I need to
include *graphics* in Imports? Note I am not asking about whether I need to
import all or any function from the *graphics* package, that is, assume I
am using graphics::abline(), etc. I am solely asking about the DESCRIPTION
file, not the Namespace.

I ask because there seems to be some ambiguity about this. I received a
pull request from someone adding *methods* to my Imports after noticing I
didn't declare it when using a function from *methods* (accessed in my
package using ::). Looking on StackOverflow, there seems to be confusion
about this. The most relevant question I could find was this one
. The question was marked as
a duplicate despite the linked duplicate being separate from it (i.e.,
asking about the Namespace, not the DESCRIPTION). Similarly, the answer to
the question does not address the question, again referring to the
Namespace and making an irrelevant distinction between Depends and Imports.
Some of the comments reference a CRAN policy, and yet that policy does not
seem to be implemented since many packages (including all of mine) omit the
base packages from the DESCRIPTION.

So, is it optional to include these packages in the DESCRIPTION? I see some
packages do so and some don't. Is including these packages filling the
DESCRIPTION with unnecessary dependencies that are automatically satisfied,
or is it being helpfully explicit about the packages your package relies
on? Thanks.

Noah

[[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

[R-pkg-devel] Should 'methods' be in Imports?

[Noah Greifer]

Hello developers,

I am wondering if base packages whose functions are used in my package need
to be present in Imports in my DESCRIPTION. For example, if I use the
function abline(), which exists in the *graphics* package, do I need to
include *graphics* in Imports? Note I am not asking about whether I need to
import all or any function from the *graphics* package, that is, assume I
am using graphics::abline(), etc. I am solely asking about the DESCRIPTION
file, not the Namespace.

I ask because there seems to be some ambiguity about this. I received a
pull request from someone adding *methods* to my Imports after noticing I
didn't declare it when using a function from *methods* (accessed in my
package using ::). Looking on StackOverflow, there seems to be confusion
about this. The most relevant question I could find was this one
. The question was marked as
a duplicate despite the linked duplicate being separate from it (i.e.,
asking about the Namespace, not the DESCRIPTION). Similarly, the answer to
the question does not address the question, again referring to the
Namespace and making an irrelevant distinction between Depends and Imports.
Some of the comments reference a CRAN policy, and yet that policy does not
seem to be implemented since many packages (including all of mine) omit the
base packages from the DESCRIPTION.

So, is it optional to include these packages in the DESCRIPTION? I see some
packages do so and some don't. Is including these packages filling the
DESCRIPTION with unnecessary dependencies that are automatically satisfied,
or is it being helpfully explicit about the packages your package relies
on? Thanks.

Noah

[[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] How to declare Bioconductor Dependencies in the Description File of my R Package

[Ivan Krylov]

В Thu, 16 Mar 2023 11:09:16 +
"Ruff, Sergej"  пишет:

> The Check-Function in R shows no Notes, Warnings or Errors, but I am
> not sure if that means that limma will install when installing my
> package from CRAN.

> Currently I am declaring limma like this:
> 
> Suggests:
> 
> limma

install.packages() doesn't install suggested packages by default: the
`dependencies` argument defaults to NA, which means c("Depends",
"Imports", "LinkingTo"), which doesn't include 'Suggests'.

What if you pass dependencies = TRUE? Given the fact that Bioconductor
is absent from getOption('repos') by default, the package will still
not be installed. BiocManager::install() is the supported way to
install packages from Bioconductor:
https://cran.r-project.org/package=BiocManager/vignettes/BiocManager.html#installing-bioconductor-cran-or-github-packages

I think that BiocManager::install('YOUR_PACKAGE', dependencies = TRUE)
will install both your package and limma. It's a bit hard to verify
because your package should live in a repository, but if you'd like to
be sure, spin up a drat  repo
on a local server and add it to options(repos = ...) before trying to
install your package.

> Do I need to declare Bioconductor-dependencies such as Limma
> differently in the Description-File of my Package?
 
No, this is the right way to declare Bioconductor dependencies for CRAN
packages.

> Can CRAN identify that limma is a Bioconductor-Package and will it
> Limma install, when installing my package from CRAN?

The CRAN website will detect the Bioconductor dependency and highlight
it with a different colour, making it a link to the Bioconductor
website. See, e.g., the BiocManager package and its reverse
dependencies: https://CRAN.R-project.org/package=BiocManager

-- 
Best regards,
Ivan

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

[R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

[Ruff, Sergej]

I am currently building a package which uses the "limma"-package as a 
dependency.

I want to submit my package to CRAN.

Do I need to declare Bioconductor-dependencies such as Limma differently in the 
Description-File of my Package?

The Check-Function in R shows no Notes, Warnings or Errors, but I am not sure 
if that means that limma will install when installing my package from CRAN.

Currently I am declaring limma like this:

Suggests:

limma



Can CRAN identify that limma is a Bioconductor-Package and will it Limma 
install, when installing my package from CRAN?

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] mzR crashing R session

[Neumann, Steffen]

Hi,

On Wed, 2023-03-15 at 16:18 +, TYLER H WINTERMUTE via Bioc-devel
wrote:
> I�m encountering the following issue when loading mzR, 
As Laurent mentioned, the warning below can safely be ignored, 
this was an issue when Rcpp changed more rapidly. 

> and my session immediately crashes.
If here you mean Segfault or other nasty surprises terminating the
session, we need more information. Also, we've seen cases of different
behaviour between rstudio sessions and bare commandline R sessions. 

Yours,
Steffen


>  I�ve followed the instructions at the GitHub wiki link, but am
> continuing to have issues. The final instruction was to send an email
> to the mailing list, which I�m doing now. Do you have any suggestions
> on fixing this issue?
> 
> Loading required package: Rcpp
> Warning: mzR has been built against a different Rcpp version (1.0.9)
> than is installed on your system (1.0.10). This might lead to errors
> when loading mzR. If you encounter such issues, please send a report,
> including the output of sessionInfo() to the Bioc support forum at
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.bioconductor.org%2F=05%7C01%7C%7C4d0b033f73e74f5f48e508db25713752%7C0934ee6c2a574efd80a9fc003defef4e%7C0%7C0%7C638144940408962856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Lemgo5U%2FjGB4n53AqPvvNWr%2FOKscaLJX7lC8SknpBWU%3D=0
> . For details see also
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsneumann%2FmzR%2Fwiki%2FmzR-Rcpp-compiler-linker-issue=05%7C01%7C%7C4d0b033f73e74f5f48e508db25713752%7C0934ee6c2a574efd80a9fc003defef4e%7C0%7C0%7C638144940408962856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=8U4UvB9QrG%2FyU0uMqjCTmpGjNsZnQ%2B962a4yrgRVD5Y%3D=0
> .
> 
> 
> Best,
> 
> Tyler
> 
> 
> [[alternative HTML version deleted]]
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

-- 
Upcoming events:
* HUPO-PSI Spring workshop April 17-19 2023 in Leiden/NL
 https://psidev.info/hupo-psi-meeting-2023 (Registration open!)



---
IPB HalleComputational Plant Biochemistry (CPB)
Dr. Steffen Neumann  http://www.IPB-Halle.DE
Weinberg 3   Tel. +49 (0) 345 5582 - 1470
06120 Halle   +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409










___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel