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
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.
> |
> |
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
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
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,
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
> 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
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:
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
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
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
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,
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
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
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
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
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
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
В 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
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,
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
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
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
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() <
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() <
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
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
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
28 matches
Mail list logo