Some packages do have a reference to bug reporting system, others do not. Where should I report package bugs then? Is there any default bug reporting system for packages which don't have their own?
I found https://bugs.r-project.org/bugzilla3/ but when I look at the components it seems more like for the R core. I also tried bug.report(package = "runjags"), but it tried to start mail program which is not very useful.
If in doubt, send an email to the package maintainer.
packageDescription("thepackagename", fields = "Maintainer")
(This is what bug.report does.)
Related
I use R pretty often and I have noticed that while checking any package's documentation at RDocumentation.org, some pages have errata so I'd like to help fix them if possible. I can't find any way to contact the website team. Any ideas?
I believe RDocumentation.org scrapes its information directly from CRAN/GitHub sources of packages, so it makes more sense to try to contact the package maintainers upstream.
Contributed packages
if a package is on GitHub, you can
fork the repository, fix the documentation errors yourself, and submit a pull request
record a GitHub issue (if there is an open issues list)
you might want to check to see if there is a README about contributions to see what the maintainers prefer
if the package is on CRAN, you can go to its CRAN page (e.g. here) and see if there is a development URL or BugReports: field in the description
if all else fails, the maintainer's e-mail is always available via maintainer("pkg_name")
Base packages
If you find documentation errors in packages that are maintained by R-core (unlikely but possible), you should probably start a discussion on the r-devel#r-project.org mailing list. Alternately, you can request write access to the R bug tracker (see here).
I've been using numtel:pg package for several projects in Meteor. Since Meteor version 1.8 the package isn't working correctly anymore. Anyone can point me to a solution?
The package seems to be abandoned, since there is no update in 4 years(!).
Trying to fix a package that is this outdated is usually not worth the effort. Your best options in this case are
find an alternative package for postgreSQL integration
find a fork of the package, that has fixed the compatibility issues
fork the package yourself and update the NPM versions or transform the package to run without hard wiring to a specific NPM version.
Resources to achieve that:
https://guide.meteor.com/writing-atmosphere-packages.html#peer-npm-dependencies
https://github.com/tmeasday/check-npm-versions
General Readings:
https://guide.meteor.com/atmosphere-vs-npm.html
https://guide.meteor.com/writing-atmosphere-packages.html
What to do if none of this applies to you, because
The alternatives require a lot of refactoring or even changes in the app architecture
There is no fork that keeps the package maintained
You are not skilled enough to fork and update the package yourself
First you should definitely open an issue on the repo and describe your problem as detailed as possible:
Meteor version, postgre version
Meteor version, postgre version where everything worked
What errors do you exactly get? Best is adding a stacktrace, if possible.
if the "error" is rather undesired behavior (not reacting, things disappear etc.) you need a very detailed description of what you did, what you expected, what (not) happened
Add screenshots if possible
Create a minimal repository that reproduces the error/issue and upload it to github; link it to your issue description
Note, that the points above also apply on Stackoverflow as criteria for a "good question". If the repo owner does not respond after a week you may trigger her attention by using #nameOfOwner in the comments.
More resources can be found here:
https://stackoverflow.com/help/how-to-ask
https://stackoverflow.com/help/mcve
By doing all these efforts you raise the chance of some community members to pick up your error (because there is less effort to reproduce when the error is documented well) and fix the issue or fork the repo.
Last but not least the golden way would be to deal with the issue, read about the package and how it works, check the code and try to fix it. Write some tests, document the fix and finally open a pull request in order to share the improvements with all the other package users.
There's a semantic error in a function of an R package written by someone else. I contacted that person which is mentioned in the 'DESCRIPTION' file of the package over email, and there is no response. But, I need to move forward with my project.
Is it possible for me to correct that error and check-in the change of that project ? If that's not possible, should I write my own version of the function with the correction and call it? What would be the best way to move forward ? Thanks.
The only way to update that particular package on CRAN is to contact the package maintainer. But you can just obtain the package's sources (you can fork it from CRAN readonly mirror on a github), fix it your way and source changed .R files after loading the package (or build entire package from sources if your fixes are in C++ code). I've done it many times. If your changes may be useful to the community, you're encouraged to create your own package.
I've included a library called blotter in my R script which has a bug in it. Is there an easy way for me to edit the source to try and debug the issue?
Look up the trace and browser functions, they are the basic tools in R for debugging. Say you want to edit the source of function foo, then saying
trace("foo",edit=TRUE)
will open up the source of foo in the editor for you to change. However, this is for interactive debugging; the source files in the packages are not changed. So once you have found the bug, you need to change the package source files for the change to be permanent.
Such a feature is implemented in the development version of R (Jul 16, 2010):
A new facility has been added to r-devel for experimenting by authors of
packages.
The idea is to insert modified code from the package source into the
running package without re-installing. So one can change, test, change,
etc in a quick loop.
The mechanism is to evaluate some files of source code, returning an
environment object which is a snapshot of the code. From this
environment, functions and methods can be inserted into the environment
of the package in the current session. The insertion uses the trace()
mechanism, so the original code can be restored.
The one-step version is:
insertSource("mySourceFile.R", package = "myPackage", functions = "foo")
See this post for further details: Inserting and testing revised functions in a package
Your question of Is there an easy way for me to edit the source to try and debug the issue? has the obvious answer: Use the source, Luke!
blotter is a package on R-Forge from where you can get blotter sources here. That is the standard way of looking at Open Source and possibly helping it along with a bug fix.
In order to be able to compare two versions of a package, I need to able to choose which version of the package that I load. R's package system is set to by default to overwrite existing packages, so that you always have the latest version. How do I override this behaviour?
My thoughts so far are:
I could get the package sources, edit the descriptions to give different names and build, in effect, two different packages. I'd rather be able to work directly with the binaries though, as it is much less hassle.
I don't necessarily need to have both versions of the packages loaded at the same time (just installed somewhere at the same time). I could perhaps mess about with Sys.getenv('R_HOME') to change the place where R installs the packages, and then .libpaths() to change the place where R looks for them. This seems hacky though, so does anyone have any better ideas?
You could selectively alter the library path. For complete transparency, keep both out of your usual path and then do
library(foo, lib.loc="~/dev/foo/v1") ## loads v1
and
library(foo, lib.loc="~/dev/foo/v2") ## loads v2
The same works for install.packages(), of course. All these commands have a number of arguments, so the hooks you aim for may already be present. So don't look at changing R_HOME, rather look at help(install.packages) (assuming you install from source).
But AFAIK you cannot load the same package twice under the same name.
Many years have passed since the accepted answer which is of course still valid. It might however be worthwhile to mention a few new options that arised in the meanwhile:
Managing multiple versions of packages
For managing multiple versions of packages on a project (directory) level, the packrat tool can be useful: https://rstudio.github.io/packrat/. In short
Packrat enhances your project directory by storing your package dependencies inside it, rather than relying on your personal R library that is shared across all of your other R sessions.
This basically means that each of your projects can have its own "private library", isolated from the user and system libraries. If you are using RStudio, packrat is very neatly integrated and easy to use.
Installing custom package versions
In terms of installing a custom version of a package, there are many ways, perhaps the most convenient may be using the devtools package, example:
devtools::install_version("ggplot2", version = "0.9.1")
Alternatively, as suggested by Richie, there is now a more lightweight package called remotes that is a result of the decomposition of devtools into smaller packages, with very similar usage:
remotes::install_version("ggplot2", version = "0.9.1")
More info on the topic can be found:
https://support.rstudio.com/hc/en-us/articles/219949047-Installing-older-versions-of-packages
I worked with R for a longtime now and it's only today that I thought about this. The idea came from the fact that I started dabbling with Python and the first step I had to make was to manage what they (pythonistas) call "Virtual environments". They even have dedicated tools for this seemingly important task. I informed myself more about this aspect and why they take it so seriously. I finally realized that this is a neat and important way to manage different projects with conflicting dependencies. I wanted to know why R doesn't have this feature and found that actually the concept of "environments" exists in R but not introduced to newbies like in Python. So you need to check the documentation about this and it will solve your issue.
Sorry for rambling but I thought it would help.