We have R-3.3.0 in our university's computing system. For some reason, the IT staffs do not want to update R version to R-3.4.0 soon. However, I need to install an R package from the GitHub, which is built on R-3.4.0. Is there any way to install that R package from the GitHub's to R-3.3.0?
#patrick's answer may work just fine. The benefit (if it works) is that you have all recent changes and functionality of the package. However, you may never know if one of the changes requiring 3.4 is about accuracy or correctness, meaning you may still get a return value but you don't necessarily know that it is correct.
For this answer, I'm going to assume that there is a valid reason to not use the current version and trick R into installing it anyway.
Grab from a specific commit
Go to the repo, https://github.com/mshasan/OPWeight in this case.
Open the DESCRIPTION file and click on the "Blame" button on the right. This brings up the commit message-header and timeframe for each group of lines with their most recent commit. In this case, it shows "Update DESCRIPTION":
Click on the description, and you're taken to the specific commit. Seeing that this is a single-line change, it is likely that an earlier commit may have been what actually changed code to use R (>= 3.4.0) a hard requirement. Take note of the commit hash (5c0a43c in this case).
Go back to the repo main page and click on "Commits". If you now search for that 7-char hash-substring, you'll see it happened on June 20, 2017. Unfortunately, the commit descriptions and timeline do not give a great expectation of where the version-depending change happened.
If you can find "the commit" that did it, then take that hash-substring and use that as your ref="..." argument to install_github. If not, however, you are either stuck (1) trying them iteratively or randomly, or (2) asking the author at which commit they started using 3.4-specific code.
Once you know a ref to use (or want to try), then run
devtools::install_github("mshasen/OPWeight", ref="5c0a43c")
(This is obviously the wrong ref to use, since that's the first commit at which we are certain the dependency exists.)
Using tests to know which to use
Since the repo contains a tests/ subdir, one can hope/assume that the tests will accurately catch if things are not working correctly in your R-3.3. This alternative method involves you testing each commit on your specific version of R (before the DESCRIPTION file was changed) until the tests no longer fail.
Using git (command-line or GUI), clone the repo to your local computer.
$ git glone https://github.com/mshasan/OPWeight
Now, iterate through the references (found using the above method or perhaps with git log) with something like:
$ git checkout --detach <hash_substring>
... and in R, run
devtools::test("path/to/your/copy/of/OPWeight")
If the tests have been set up correctly and you chose a worthy version, then stick with it.
You can find the description file for OPWeight here.
Change this part
Depends:
R (>= 3.4.0),
to whatever R you are using and see if things break. The logic of the description file is explained here. Obviously a last resort.
Related
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.
I tried to use AFP (02/22/2021) with Isabelle 2021, but the jEdit/Isabelle PIDE wouldn't load after the AFP directory is added to the user ROOT file. The is shown below and seems to be about a specific package:
I don't really need the entry in question (, or know what it does).
My question is:
Is there a way to use a subset of AFPs and exclude problematic entries in the screenshot?
-- Update ---
As pointed out in the comments, the AFP seemed to be lagging a couple of days behind. Using afp-02-24-2021, the initial error went away. However, when selecting a session Jordan-Normal-Form from jEdit, there is a new error about JNF-AFP-Lib build failing, as shown below:
The question remains. The AFP seems to be a large collection and there could be multiple sources of error.
In case of such errors, is there a way to select a subset of AFPs to use or debug?
If not, is there a systematic way to test which afps do or do not build?
Original question
The problem was because you (unknowingly) used an AFP release that did not match the Isabelle release. To avoid that problem in the future, I recommend using the Mercurial repository directly:
https://foss.heptapod.net/isa-afp/afp-2021
The Mercurial repository for a new Isabelle release gets created during the RC phase, so you can always be sure to have matching versions.
In the case of these mismatches, it is usually not possible to select a subset of the AFP that "works", because between 2020 and 2021, the session management has changed considerably.
Update
The problem you're facing here is that you have selected a big session as a prerequisite and it takes too long to build with the default configuration.
You can build the session on the command line with an increased timeout as follows:
isabelle build -bv -d <path to afp>/thys -o timeout_scale=3 Jordan_Normal_Form
Increase the factor if it keeps timeouting.
General remark
You ask, "In case of such errors, is there a way to select a subset of AFPs to use or debug?". The answer to that question depends on the kind of error. Your post currently contains two vastly different problems, so it's not possible to give a general answer, unfortunately.
I am currently writing a text with R bookdown and asked two friends to read my text and give comments, corrections and general feedback. My source files for the text are stored on GitHub and I would like my collaborators to make changes in the files (one for each chapter) with the help of git. However, none of us are really experts on git. This makes it hard to figure out what a suitable workflow is.
For now, we decided that each one of them creates himself a branch so that he does not directly push into the master branch. After I have read their changes I would like to decide what I merge into the master branch and what not. So far, it looks like each change needs to be in a separate commit because I am not able to merge single lines from a specific commit (not sure if that is at all possible). However, this seems like a lot of annoying and unnecessary commits to create. So, I guess I am looking for a way to avoid that and/or general pointers towards a good workflow for such kind of projects.
A useful command will be git cherry-pick, it allows you to select specific commits from a branch.
A general good practice is that commits should be self contained (if applied alone they make sense) and they target a specific feature (in the use case mentioned, that could be a paragraph or a section or a chapter).
In the end, if you would like to apply only specific changes of a commit, that would have to happen manually, someone has to decide which parts to apply and which not. A commit can be edited using git rebase -i <branch name> before being merged. This question might also be useful.
I finally found what worked for me in here. Basically, on my master branch I had to use
git merge --no-commit --no-ff branch-to-merge
This will merge all changes into my master branch but does not immediatly commit the changes so that they can still be staged/unstaged. Then, I can decide what line change to include by staging the line changes I want to keep and discard all other line changes. Finally, I commit all staged line changes et voilà, that's what I wanted to get.
Sidenote: I am using gitkraken and as a beginner with git I enjoy using the GUI but the merge part with the options "no-commit" and "no-fast-forwarding" had to be done via the git console (at least I could not find a way to to that using the GUI). Choosing which lines to stage and which to discard is then an easy task via the GUI.
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.