I currently have quantmod installed. I would like to modify the source code.
Do I need to uninstall the current version?
I currently was trying
(1) Installed GIT
(2) then I went to New Project>> Version Control >>create a new project form version control GIT and when I click that I get this error
"Git was not detected in the system path. to create projects from GIT repositories you should install GIT and then restart Rstudio. Not tha tif GIT is installed an not on the path then you can specify its location using the options dialog."
(3) So I went to the global options>>GIT/SVN>>Git executable and put this path
C:\Users\me\AppData\Local\Programs\Git\bin\git.exe
(4) then I restarted RSTUDIO and now I get further so when I go to
New Project>> Version Control >>create a new project form version control GIT>>CLONE GIT REPISITORY
Here it asks for a Repository URL, Project Directory name, and Create project as subdirectory of. Here is where I am unsure where I need to put this project so that the modification I make to the quantmod package will be picked up by my version of R
For Repository URL I was going ot put:
https://github.com/joshuaulrich/quantmod
For Project Directory I am unsure: can you advise??
For Create project as sub directory I am unsure: can you advise??
My R libraries are here: C:\Users\me\Documents\R-3.1.2\library
Also currently I have quantmod installed here:
C:\Users\me\Documents\R-3.1.2\library\quantmod
Do I need to uninstall that current version?
Appendix:
On My computer GIT is here: C:\Users\Me\AppData\Local\Programs\Git
On My computer R is here: C:\Users\Me\Documents\R-3.1.2
The project directory is just the name of the folder you will be putting the repo inside. Generally it is the name of package to make things clear. In your case quantmod.
The sub directory you can ignore unless you want to choose some other location (besides the current directory) for you code.
You don't need to uninstall the current version. My usual recommendation is to just increment the subversion of the package in the DESCRIPTION file. For example, increment:
Version: 1.0.1
to
Version: 1.0.2
Now when you rebuild and install you will have the new version. If you need the original again, you can just reinstall the old one (i.e. install.packages). Having both installed at the same time would likely result in conflicts between the packages and just causing a headache.
Related
I want to start using package management for R projects. I am trying to use the packrat package. When I start a new project, I select the "Use packrat with this project" in the GUI. Or I could use packrat::init(). Both work OK. However, unless I am misunderstanding, this only initialises with a selection of packages which means I have to re-install lots of packages manually?
For example, after starting a project from scratch I have to re-install ggplot2 or pool or many others manually but not e.g. dplyr or DBI.
My question is, can I edit the list of standard packages that get initialised for a new project? Otherwise, for every new project I create I will have to go through and manually install lots of packages. I feel like I am missing a crucial step somewhere?
I would say create a new directory call the directory: "Quickstart."
Then install packrat and all the libraries you want to use into Quickstart.
Then when you want to start new project:
copy/paste the Quickstart/packrat folder into your new project directory
copy/paste the Quickstart/.Rprofile file into your new directory
Now your new project should have all the starting libraries and packrat initiated.
I git clone a package from github and checked the version inside that folder:
>meteor --version
Extracting meteor-tool#1.4.2_7... (forever running)
Then I go outside of that folder:
>meteor --version
Meteor 1.4.3.1
How can I run the global version inside a meteor project folder?
It is because that meteor project you checked out from github is targeting 1.4.2_7. Everytime you create a new meteor project, it saves the version that you used to create it (in a file inside the .meteor folder) so that if the api changes in new future versions, your project will still run (since it targets a specific version in time).
Because of this, when you go to run the project later, it will always use the targeted version (the version used to create the project.). If that version is not on your system, then it will download and install it first before running the app. This is what you have observed. It is downloading that certain version and it can take a very long time to do this depending in your connection speed (it often takes 15 - 25 minutes to do this on my machine at home.
One note, the project's meteor version can be changed by calling meteor update
I have just began working on Atom.io Package development, and based on this tutorial, have learnt from how to create package development skelton file to how to publish your package.
However, I do not know how to check/debug/develop your package. I know I can use Jasmine via alt-cmd-I or Developer Console (for Atom is based on Chromium), still if you want to check the behavior of your package, do I have to re-publish or install your package manually every time?
When working on packages locally, here's the recommended workflow:
Clone your package from GitHub using apm develop <package-name>. This will clone the package's repo to your local ~/.atom/dev/packages/<package-name>
cd into this directory
Start Atom in this directory using atom -d .
Now you can work on the package, make changes, etc. Once you're ready to reload, you can use View > Developer > Reload Window to restart Atom with the changed package.
If you have your package sources locally on your machine, you can skip the first step (apm develop) and simply create a symbolic link from your sources to ~/.atom/dev/packages/<package-name.
Already have a local repo of the package?
To add to nwinkler's answer, if you already have a repo of the package locally, you can use
apm link --dev
to automatically create a symbolic link to the ~/.atom/dev/packages/ directory.
Make sure to completely restart atom in developer mode with
atom -d
or in View > Developer > Open In Dev Mode...
If you just want to use a local package (not in dev mode), you can use apm link directly. And apm unlink to remove the symbolic link to ~/.atom/packages.
I installed couple of packages for 'Project A' (e.g bootstrap) assuming that it will be available for all subsequent projects. But when a new meteor project 'Project B' was created, meteor list showed only default packages. So my assumption that meteor packages are like ruby gems available globally is incorrect. As I work offline every now and then, Is there a way I can manually copy/re-use installed packages?
Yes they are similar to gems. Packages are installed in ~/.meteor/packages, in precompiled form. They can be installed globally this way.
When you add a package to your project it will essentially copy the package from there into your build-cache directory hidden in the .meteor directory of your project.
To install a package locally where you can easily re-use it you would have to clone the github repository of the package and place the output in the /packages directory of your Meteor app.
For example for bootstrap, twbs:bootstrap you would clone this reposistory: https://github.com/twbs/bootstrap, into a directory like /packages/twbs:bootstrap (name doesn't matter if its defined in the package.js file on the repository.
In general you can easily re-use a package without the hassle of adding it in manually like so. It's better to use the global packages which are kept up to date.
The trouble comes with being offline. If you use a local package its nearly guaranteed to always work. Whereas the global ones can give a bit of trouble once in a while when you try to add a package in as meteor tries to check the package is up to date, especially where npm packages are involved with the package.
To keep it short if you added a package in using meteor add twbs:bootstrap you should most likely be able to add it to another project using the same command. Only if you keep your packages & meteor up to date.
When developing packages in RStudio.
By default RStudio assume your package directory is the project directory and it looks like that:
But you are allowed to point the package location to a subdirectory of the project directory and it looks like that:
This way you can have some part of your project files, kept in the root project directory, not included in the package. You don't need to set git ignore etc.
But if you want to add RStudio git repo features, you are not allowed to point your git repo in subdirectory, even if you have already created git repo in your package dir (not project dir) you cannot set it in RStudio. I'm stuck at:
Is there any way to enable git repo features in RStudio having git repository in the subdirectory of the RStudio project? Maybe some .Rproj config tweaks?
Very good question. I've experienced the same trouble and it also does not go away with the latest pre-test release. So there's likely no super quick solution to this inside rstudio. Though it might be worth a feature request.
Personally I use the console / git bash with git and rstudio. That is I create a project inside R studio and manually run git init outside rstudio. Also I add, commit, merge, push and pull outside rstudio. If you don't like to manage git via console there's https://windows.github.com/ and https://mac.github.com/ also the folks at Atlassian provide some GUI tool called source tree: https://www.atlassian.com/software/sourcetree/overview
Plus there are many others, like Tortoise Git which I haven't tested, but I think R Studio's current git support is fine for simple things, but a git tool (console or gui) is definitely the way to go if you want to be more flexible.
That being said, sublime text edit is a powerful and easy to hack and customizable text editor which also has quite some packages to extend it. It's not entirely free but sometimes it's a nice supplement to rstudio. And it has a cool resolve conflict package etc.