search for: otherpkg

...example, but it can happen in other similar cases.) The key here is that R6 is a build-time dependency of yourpackage, similarly to packages linking to (i.e. LinkingTo) Rpp. Another possible type of build-time dependency is if you put objects from another package in yourpackage. E.g. myfun <- otherpkg::fun Then a copy of otherpkg::fun will be saved in yourpackage. If you install a new version of otherpkg, yourpackage is unaffected, and if otherpkg::fun uses some (possibly internal) API from otherpkg, that has changed in the new version of otherpkg, you might easily end up with a broken yourpack...

On 16/12/2016 12:35 PM, Karl Millar wrote: > A couple of points: > - rebuilding dependent packages is needed if there is an ABI change, > not just an API change. For packages like Rcpp which export inline > functions or macros that might have changed, this is potentially any > change to existing functions, but for packages like Matrix, it isn't > really an issue at all

I'm trying to keep debugging of a development package relatively sane. I see that some packages manage to incorporate what appears to be Subversion (SVN) revision information in the package description; for example, > library(MASS) > sessionInfo()$otherPkgs$MASS$Revision [1] "$Rev: 3016 $" which looks like an auto-generated revision number. On the other hand, the rgl package (for example) appears to manually encode the SVN revision in the package number: > library(rgl) > sessionInfo()$otherPkgs$rgl$Version [1] "0.92.829&qu...

...geDescription) if (length(package) == 0) stop("no valid packages were specified") basePkgs <- sapply(pkgDesc, function(x) !is.null(x$Priority) && x$Priority == "base") z$basePkgs <- package[basePkgs] if (any(!basePkgs)) { z$otherPkgs <- pkgDesc[!basePkgs] names(z$otherPkgs) <- package[!basePkgs] } loadedOnly <- loadedNamespaces() loadedOnly <- loadedOnly[!(loadedOnly %in% package)] if (length(loadedOnly)) { names(loadedOnly) <- loadedOnly pkgDesc <- c(pkgDesc, lapply(lo...

...adata object)) and what happens to the *object* itself. Or in other terms, whether a namespace (possibly locked) needs to be updated, or the (state of the) object itself is what needs to be updated. I'll try and explain below. If `mypkg` want to use a function called `other_fun` from package `otherpkg` all I have to do is import the *name* of `other_fun` into the `mypkg` namespace. After that all the magic of making sure that the other_fun *object* works and can find everything it needs is taken care of for me. The other_fun object knows the enclosing environment where it was created and finds...

...g a package with library(APkg) or require(APkg) I would like to make sure that (1) the correct version of [R] is installed. If not an informative error message should be given. I would also like to make sure that (2) another required package which is loaded from within the APkg package (by require(OtherPkg)) is of a certain version or later. First of all, I believe that the check should be done in .First.lib(), correct? To check for the correct version of [R] I would guess that R.Version()$major and R.Version()$minor could be used to retrieve the version. Is there any prewritten function to compare...

On looking more closely, the purpose of finding the class definition is to update the entry for the new relationship, as the warning message suggests. That requires that the namespace holding the definition be writable. In the case of subclass information, the original namespace is very likely to be locked, if it's not the package currently being loaded. Copying the definition in order to

Hi, Two easy questions I'm sure. 1) As an example if I use the code require(zoo) then once it's loaded is there a command that lists everything that zoo provides so that I can study the package? Certainly help(zoo) gives me some clues about what zoo does but I'd like a list. Maybe there's a way to query something but in Rgui under Win Vista ls() returns nothing after zoo

Hi, after updating R 2.5.0 devel yesterday we today observed many new unexpected failures in our daily package build and test system runs, which can be traced to recent changes in the implementation in try() (as noted in NEWS). Investigating this new implementation I come across an issue in conjuntion with using S4 classes and methods. try(expr) does not return an object with attribute