I've noticed that the {ggflags} package is no longer supported in R. Does anybody know if there's an alternative for plotting points as country flags as it could've been done with geom_flag?
ggflags has never been officially supported (meaning available on a formal archive like CRAN) - it's a package in github, basically in eternal development.
There are two versions of ggflags around: One with round flags (https://github.com/jimjam-slam/ggflags) and one with rectangle flags (https://github.com/ellisp/ggflags).
Your options: you could fork into that repository in github and update it to work for later versions of R, e.g. with a pull request or you just keep your own version of it. This certainly requires a certain knowledge of how to write packages (I've learned that with Hadley's help: https://r-pkgs.org/). You will do the community a great service, I honestly encourage you to do so:)
Or, if you feel open for some risks, you could download the package and just update the description file by removing unwanted dependencies. Code might fail, but there is a chance that it will work. Don't worry, you won't kill your computer doing that.
https://stackoverflow.com/a/30564896/7941188 tells you how to do this.
Related
Coming from an R background, and just started learning Julia, I wonder how's documentation in Julia, and if there are analogues to R's help pages and vignettes.
Furthermore, in R, one can document functions using roxygen comment blocks, is there also something similar in Julia?
I think it is best to understand how things work by example. I will comment on how DataFrames.jl is documented as this is a pretty standard approach:
Functions are documented using docstrings, here is an example of a docstring of function names; These docstrings are then discoverable interactively via help system (by pressing ?)
A standard way to generate a documentation for a package is to use Documenter.jl; by the way: the package has a great team of maintainers who are very helpful and responsive; here you have a link to the make.jl file that is executed to generate the documentation; note in particular the option doctest=true which makes sure that all code examples that are properly anoteted following Documenter.jl rules are producing an expected output
In order to set-up auto-generation of package documentation you need to set up CI integration on GitHub; again - there are many ways to do it; a standard one is to use GitHub Actions; here you have a link to the part of the ci.yml specification file that ensures that documentation is built as a part of CI; then in any PR, e.g. this one (I am giving a link to a currently open PR that is documentation related) you can see in the section reporting CI results that after running tests also documentation was generated. Here you can see how a documentation generated using this toolchain looks like (e.g. note that at the bottom you can switch the version of the package you want to read manual of dynamically which shows you that all here is really well integrated - not just a bunch of PDF or HTML files).
I hope this will help you to get started. I have pointed you to all essential pieces that are normally used by packages hosted on GitHub (i.e. this is not the only way to do it, but it is a standard way most commonly used).
To master all the details of the above you need to read the documentation in the Julia Manual and Documenter.jl carefully. Unfortunately writing a proper documentation is not easy (in any programming language). The good thing is that Julia has a really excellent toolchain that supports this process very well.
I'm working on a fork of a package that depends upon the ReporteRs library.
However, this library has been deprecated by its owner for a few years, in favour of the officer and flextable libraries.
On of the main reasons for this depreciation is not to depend on rJava, which may cause installation problems and bugs.
In my package, how should I manage this case?
So far, my package was processing data to return a ReporteRs object. If I change my functions to return an officer object I would break backward compatibilty.
But if I don't, and keep old, ReporteRs returning function as legacy backward compatibilty functions, I have to keep ReporteRs in my dependencies and my package would be rJava-dependant.
Is there a win-win solution?
Here is what I would do:
Make your best attempt to re-implement your functions with the officer library, but keeping your old API. Make sure that you warn the users that these functions are deprecated. At the same time make new functions fully compliant with officer/flextable syntax. Note that you might change the behavior of the functions slightly (as in, not ensuring all parameters are properly evaluated), as long as they take the same parameters and return the same type of objects.
If that is really not possible, just add a compatibility warning to your old functions.
Create a transitional package version that you would keep around for a few weeks or months with both versions of these functions. If the package still needs to depend on rJava, tough luck.
Keep track of the packages that depend on your package. If there are not too many, you can contact their developers directly. Maybe the issue is not as serious as you think it is?
EDIT: As discussed above, you can make your dependency on ReportR conditional on the availability of ReportR. Then, you can put ReportR into the Suggests field of the DESCRIPTION file rather than Depends, and in the package you can use code like this:
if(requireNamespace("ReportR")) {
warning("This function is deprecated, better use MyNewFunction instead")
ReportR::whatever() ...
} else {
warning("To run this (deprecated) function, please install the ReportR package")
}
I intend to use a package which requires Julia v1.0.0
I have used other versions like v0.7.0, v1.0.4 and later releases but non of them works with the package.
If the package you are after is not working with 1.0.4 there are solid chances that it will not work with 1.0.0 either, or that it is relying on an unintended feature, colloquially also known as bug.
However, to get binaries for different versions of Julia, you have a number of options.
Option 1
Go to the Download page of the Julia website and grad the version you need.
However, not all available downloads have a corresponding link.
In your specific case, you should pick up the binary corresponding to the architecture you are interested in, copy the link, modify the link to replace the version info, and finally use the link.
For example, starting from: https://julialang-s3.julialang.org/bin/winnt/x64/1.0/julia-1.0.4-win64.exe
Replace 1.0.4 with 1.0.0:
https://julialang-s3.julialang.org/bin/winnt/x64/1.0/julia-1.0.0-win64.exe
(I am not sure how long this trick would work).
Option 2
This is the safest method because it relies on the actual source history of the project (version control systems were made also for this).
You basically grab / check out the source:
https://github.com/JuliaLang/julia/releases/tag/v1.0.0
And then you would compile it yourself.
Instructions on how to do that are available here.
My package introduces registry entries. Changes by site administrator should not be overwritten on reinstall of the package.
Many ways to Rome. I chose ftw.upgrade. I like the declarative way of the upgrade step syntax. Its possible to use an upgrade directory for generic setup xml-Files like propertiestool.xml. No need to define handler python code. The upgrade works well. The admin can upgrade from control panel and in my case the new property is added. Insomma: For a new property just these have to be added: an upgrade-step declaration for source and destination version and directory where to find the properties.xml. Thumb up! –
You can pilot what to do when installing a Plone add-on by providing an Extension/install.py file with a install method inside:
def install(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-your.pfile:default')
This way you are driving what Plone should do when installing.
If you need it: the same if for uninstall:
def uninstall(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-example.gs:uninstall')
This way you can prevent the uninstall step to be run when reinstalling.
Warning: as Mathias suggested using quickinstaller -> reinstall feature is bad.
Warning: this will not probably work anymore on Plone 5 (there's open discussion about this).
I think what you describe is one of the problems upcoming with the increasing complexity of Plone's stack, and one of the reasons, why it is not recommended to execute a re-install anymore, but to provide a profile for each version of the Add-On, via upgrade-steps (as Mathias mentioned). That increases dev-time significantly and results in even more conflicts, of my experience. Here are the refering docs:
http://docs.plone.org/develop/addons/components/genericsetup.html#add-upgrade-step
Elizabeth Leddy once wrote an Add-On to ease that pain and I can confirm it does:
https://github.com/ampsport/amp.ezupgrade
And the great guys from FTW, too, I never used it, but looks promising:
https://pypi.python.org/pypi/ftw.upgrade
Neither used this one, even claims to have some extra goodies, like cleanup broken OFS objects and R. Patterson's on it:
https://github.com/collective/collective.upgrade
As we're here, the first good doc I could find about it ~ 1.5 years ago, comes from Uwosh, of course:
http://www.uwosh.edu/ploneprojects/docs/how-tos/how-to-use-generic-setup-upgrade-steps
Another solution can be, to check, if it's an initial- or re-install, and set the properties programatically via a Python-script, conveniently called 'setuphandlers.py', like described in this answer:
How to check, if my product is already installed, when installing it?
That way one can still trigger re-installs without blowing it all up.
Lastly, a lot of the GS-xml-files understand the purge-property, setting it to False, will not overwrite the whole file, just your given props. This might, or not, apply to your case, you can find samples in the above referenced official doc.
I have several custom functions that I use frequently in R. Rather than souce this file (or parts thereof) in each script, is there some way to add this to a base R file such that they are always available when I use R?
Yes, create a package. There are numerous tutorials as well as the Writing R Extensions manual that came with your copy of R.
It may seem like too much work at first, but you will probably be glad that you did this in the longer run.
PS And you can then load that package from ~/.Rprofile. For really short code, you can also define it there.
A package may be overkill for a for a few useful functions. I'd argue there's nothing wrong with explicitly source()ing them as you need them - at least it is explicit so that if you email someone your code, you won't forget to include those other scripts.
Another option is to use the .Rprofile file. You can read about the details in ?Startup. Basically, the idea is that:
...a file called ‘.Rprofile’ is searched for in the current directory or
in the user's home directory (in that order). The user profile file is
sourced into the workspace.
You can read here about how many people use this functionality.
The accepted answer is best long-term: Make a package.
Luckily, the learning curve for doing this has been dramatically reduced by the devtools package: It automates package creation (a nice assist in getting off on the right foot), encourages good practices (like documenting with roxygen2, and helps with using online version control (bitbucket, github or other), sharing your package with others. It's also very helpful for smoothing your way to CRAN submission.
Good docs at http://adv-r.had.co.nz and http://r-pkgs.had.co.nz .
to create your package, for instance you can:
install.packages("devtools")
devtools::create("path/to/package/pkgname")
You could also look at the 'mvbutils' package: it lets you set up a hierarchical set of "tasks" (folders with workspace ".RData" files in them) such that you can always see what's in the ancestral tasks (ie the ancestors are in the search() path). So you can put your custom functions in the "starting task" where you always start R; and then you change to vwhatever project-specific task you require, so you can avoid cluttered workspaces, but you'll still be able to use (and edit) your custom functions because the starting task is always ancestral. Objects (including functions) get stored in ".RData" files and are thus loaded/saved automatically, but there are separate text-backup facilities for functions.
There are lots of different ways of working in R, and no "one-size-fits-all" best solution. It's also not easy to find an overview! Speaking just for myself:
I'm not a fan of having to 'source' everything in every time; for one thing, it simply doesn't work with big data sets and/or results of model runs.
I think packages are hard to create and maintain; there is a really significant overhead. After the first 5 packages you write, it does get a bit easier provided you do it on at least a weekly basis so you don't forget how, but really...
In fact, 'mvbutils' also has a bunch of tools for facilitating the creation and (especially) maintenance of packages, designed to interface smoothly with the task-hierarchy system. I use & edit my own packages all the time (including editing mvbutils itself); but if it wasn't for the tools in 'mvbutils', I'd be grinding my teeth in frustration most days of the week.