On 02/08/2016 6:34 PM, Dirk Eddelbuettel wrote:
On 2 August 2016 at 18:13, Duncan Murdoch wrote:
| Okay, now I think I understand, but I agree with CRAN. It is not
| feasible to tell if the test happened somewhere in the code unless we
| enforce a particular way of writing the test.
Debian has
On 2 August 2016 at 18:13, Duncan Murdoch wrote:
| Okay, now I think I understand, but I agree with CRAN. It is not
| feasible to tell if the test happened somewhere in the code unless we
| enforce a particular way of writing the test.
Debian has well over 20k packages, and they are tested thi
On 02/08/2016 4:20 PM, Dirk Eddelbuettel wrote:
On 2 August 2016 at 16:07, Duncan Murdoch wrote:
| On 02/08/2016 1:41 PM, Dirk Eddelbuettel wrote:
| >
| > On 2 August 2016 at 13:12, Duncan Murdoch wrote:
| > | On 02/08/2016 1:01 PM, Dirk Eddelbuettel wrote:
| > | >
| > | > On 2 August 2016 at 11
Not strictly what you're asking, but at some point it may be important to note
that the "QR" method used by lm() and friends (notably anova() and aov())
actually relies on successive orthogonalization. This does yield a QR
decomposition but the reverse is not true. A generic X=QR decomposition d
>> It is really simple: Having _both_ Suggests: foo _and_ an unconditonal
>> call
>> to foo::bar() in the code.
>>
>> Whereas Josh and I argue that it needs to be conditional on requireNames()
>> coming back TRUE.
>
>
> I am feeling particularly dense today. What about "Having _both_ Suggests:
>
On 2 August 2016 at 16:07, Duncan Murdoch wrote:
| On 02/08/2016 1:41 PM, Dirk Eddelbuettel wrote:
| >
| > On 2 August 2016 at 13:12, Duncan Murdoch wrote:
| > | On 02/08/2016 1:01 PM, Dirk Eddelbuettel wrote:
| > | >
| > | > On 2 August 2016 at 11:36, Joshua Ulrich wrote:
| > | > | Maybe I'm miss
On 02/08/2016 1:41 PM, Dirk Eddelbuettel wrote:
On 2 August 2016 at 13:12, Duncan Murdoch wrote:
| On 02/08/2016 1:01 PM, Dirk Eddelbuettel wrote:
| >
| > On 2 August 2016 at 11:36, Joshua Ulrich wrote:
| > | Maybe I'm missing something, but isn't that the point of calling
| > | requireNamespace
My concerns with installing on the fly are that it (1) requires internet
access during run time, and either (2) involves assumptions about
repository and library locations, or (3) requires exposing all arguments to
install.packages() via higher level functions, or (4) needs interactivity.
-Thomas
On 2 August 2016 at 11:00, Kevin Ushey wrote:
| You could abuse the LinkingTo: field of the DESCRIPTION file, to
| specify 'packages you want installed alongside your package that you
| won't necessarily use at runtime'. (It's possible that 'R CMD check'
| might warn about strange usages of Linkin
Hello,
I am currently working on an implementation of QR decomposition (leveraging
a C++ library via Rcpp). Naturally I would like to have the R syntax as
similar as possible to base R 'qr' function. Given the class structure of
my package my instinct was to export an S4/S3 method.
However, the
You could abuse the LinkingTo: field of the DESCRIPTION file, to
specify 'packages you want installed alongside your package that you
won't necessarily use at runtime'. (It's possible that 'R CMD check'
might warn about strange usages of LinkingTo:, but I'm not sure)
You could also just place thes
On 2 August 2016 at 13:12, Duncan Murdoch wrote:
| On 02/08/2016 1:01 PM, Dirk Eddelbuettel wrote:
| >
| > On 2 August 2016 at 11:36, Joshua Ulrich wrote:
| > | Maybe I'm missing something, but isn't that the point of calling
| > | requireNamespace()? For example:
| > | if (requireNamespace("sugg
On 02/08/2016 1:01 PM, Dirk Eddelbuettel wrote:
On 2 August 2016 at 11:36, Joshua Ulrich wrote:
| Maybe I'm missing something, but isn't that the point of calling
| requireNamespace()? For example:
| if (requireNamespace("suggestedPackage"))
| stop("suggestedPackage required but not installed
On 2 August 2016 at 11:36, Joshua Ulrich wrote:
| Maybe I'm missing something, but isn't that the point of calling
| requireNamespace()? For example:
| if (requireNamespace("suggestedPackage"))
| stop("suggestedPackage required but not installed")
|
| That doesn't seem like a heavy burden for
Dirk,
That is useful. I think the "Recommends" category from that link is
pretty much what I am suggesting - something that should be installed
if it's available in the package repository but is not loaded/imported
by default.
Some of those other relationships sound like they would also be
useful
On Tue, Aug 2, 2016 at 11:26 AM, Thomas J. Leeper wrote:
> I have a fairly open-ended question about the handling of package
> dependencies that is inspired by the precise distinction between
> "Depends", "Imports", and "Suggests" listed in DESCRIPTION.
>
> Some background, as I understand it: Pri
See eg https://www.debian.org/doc/debian-policy/ch-relationships.html
We have other big fish to fry. Eg many packages have LinkingTo: BH (as Boost
headers are indeed awesome) but this 120 mb (!!) payload is needed _once_
during package compilation / installation and never again afterwards. So
B
I have a fairly open-ended question about the handling of package
dependencies that is inspired by the precise distinction between
"Depends", "Imports", and "Suggests" listed in DESCRIPTION.
Some background, as I understand it: Prior to requiring package
namespaces, we listed package dependencies
18 matches
Mail list logo
