My personal opinion is that as long as a package doesn't actually make it on to
CRAN, you don't need to bump the version. It's worked so far
-Original Message-
From: R-package-devel On Behalf Of Ben
Bolker
Sent: Saturday, 24 October 2020 2:23 AM
To: r-package-devel@r-project.org
I set \dontrun{} on (most of) the examples in my Azure-related packages, for
this very reason. They assume the user has an Azure subscription, and in any
case, you don't want to be running code that could potentially cost lots of
money just for kicks. The packages in question are basically all
Yes, that’s the one.
From: Rainer M Krug
Sent: Tuesday, 23 June 2020 11:12 PM
To: Hong Ooi
Cc: R Package Devel
Subject: Re: [EXTERNAL] [R-pkg-devel] Proper CRAN way - How to handle
dependency of java jar file?
Thanks Hong - I like that.
I found that package in the tools::R_user_dir()
Another possibility, if you want the jar to be dynamic and also have a standard
location for it, is to write it to the R config/user dir. This is available via
R_user_dir() in R 4.0 (and earlier versions via the backports package). An
older alternative that still works is to use the rappdirs
Hello all,
I'm refreshing the docs for my SAR package ( https://github.com/hongooi73/SAR
), and I'm running into a weird problem.
The package contains 2 example data frames, 'ms_catalog' and 'ms_usage'. Here
is the relevant documentation for them, in the file R/ms_data.R:
#' Sample usage
I tend to agree. Having ... as an argument for a specific method is often
unnecessary, and furthermore, can result in errors being hidden. Eg you think
you're calling
methodname(arg1, arg2="whatever")
but you're really calling
methodname(arg1, ar2="whatever")
and the misspelling isn't picked
before calling build.
But the question is why are these ignored directories scanned before building
the package? They should be ignored anyway?
Rainer
Gabor
On Mon, Feb 10, 2020 at 4:54 PM Hong Ooi via R-package-devel
<mailto:r-package-devel@r-project.org> wrote:
Actually, cancel that:
00.tar.gz'
>
> This is really weird, I'm used to the package prep step taking 10 seconds at
> most.
>
>
> -Original Message-
> From: R-package-devel On Behalf Of
> Hong Ooi via R-package-devel
> Sent: Tuesday, 11 February 2020 3:50 AM
> To: r-package-devel@r-p
10 seconds at
most.
-Original Message-
From: R-package-devel On Behalf Of Hong
Ooi via R-package-devel
Sent: Tuesday, 11 February 2020 3:50 AM
To: r-package-devel@r-project.org
Subject: [EXTERNAL] [R-pkg-devel] R CMD build hanging for some but not all
packages
This is with R 3.
This is with R 3.6.2 on Windows 10 Pro 1909.
In the last couple of weeks, devtools::build() and devtools::check() have
started hanging on some, but not all, of my packages. After some poking around,
I discovered that it's actually R CMD build that is having problems, right
after the "checking
I echo this. Relying on something undocumented and platform-specific, like the
location of a random installation file, is just asking for problems. Instead,
make a small image of your own and distribute it with your package.
-Original Message-
From: R-package-devel On Behalf Of Ben
Good catch, Ivan! Fixing that seems to have done the trick. Thanks!
The question now is why checkpoint hasn't crashed and burned prior to this, but
I'll leave that for another day
-Original Message-
From: Ivan Krylov
Sent: Friday, 10 January 2020 8:18 PM
To: Hong Ooi via R
Hi all,
I'm the new (as of 6 months ago) maintainer of checkpoint. If you're not
familiar with it, checkpoint is a package to help with reproducible analysis:
you give it a particular snapshot date from the MRAN site, and it installs the
packages that your project depends on from that
Also, consider using the rappdirs package to write to a location that follows
standard practice on each platform.
-Original Message-
From: R-package-devel On Behalf Of
Martin Maechler
Sent: Thursday, 17 October 2019 11:44 PM
To: Sigbert Klinke
Cc: r-package-devel@r-project.org
Hm, up to now my AzureR packages haven't met with any issues, and they are
basically API wrappers.
I did have one reviewer ask for runnable examples when I submitted one package,
but replying and pointing out the issues you mention cleared things up. I did
cc Uwe Ligges in the reply, who
--- Begin Message ---
I don’t think they check _every_ help page for examples. My assumption would be
that if the main functionality of the package is covered, then functions that
are clearly ancillary, or whose usage is obvious, get a pass.
Another reason for cloud-related packages to mark
--- Begin Message ---
I had a similar experience with a couple of my package updates needing changes.
The background is that I have a family of packages for talking to Microsoft's
Azure cloud service from R, and my examples are all marked \dontrun because
they need an Azure subscription to
--- Begin Message ---
Don't want to turn this into a pile-on, but I also think this isn't a very good
idea. As I understand it, accessing the symbol "foo" will pull the latest
version of foo from the remote site. This has consequences for reproducibility,
because now your code could be exactly
--- Begin Message ---
The various devtools::install_* functions don't install vignettes by default;
to do so, add the build_vignettes=TRUE argument.
-Original Message-
From: R-package-devel On Behalf Of
Troels Ring
Sent: Friday, 1 February, 2019 10:15 PM
To: package-develop
Subject:
--- Begin Message ---
It looks like the ".rdata" in your package name is confusing R CMD BUILD into
thinking there is a .rdata file involved. Consider renaming it to "bcmaps.data"
or something similar.
-Original Message-
From: R-package-devel On Behalf Of Sam
Albers
Sent: Friday, 11
--- Begin Message ---
Just a few comments:
- Given vioplot 0.2 is 12 years old, I wouldn't be TOO concerned with backward
compatibility. I wouldn't ignore it either, but if I had to choose, I'd go for
modern idioms over ensuring that everything works exactly the same.
- You don't need to keep
--- Begin Message ---
This looks like a similar situation to the C++ Boost headers, which are
packaged up for easy R consumption in the boost package. You could try doing
that with BerkeleyDB.
There's another issue though: looking at your FAQ page, you seem to rely on a
bunch of tools written
--- Begin Message ---
I do use subclassing as you suggest. In my base package I have an az_resource
class that represents any generic Azure resource. Eg in the VM package, I
extend it to obtain az_vm_resource; in the storage package I extend it to
obtain az_storage; and so on. In addition to
--- Begin Message ---
I'm writing a family of packages for talking to Azure (Microsoft's cloud
service) from R. The basic architecture is
AzureRMR: the "base" package, provides a number of R6 classes
AzureVM: a "child" package that extends classes from AzureRMR with extra
functionality related
24 matches
Mail list logo
