I am using RStudio to build a R package. I am able to create a New Project -> R package -> Package name and add R files. This then creates all the appropriate folders with the R files and the .Rd files in the man folder.
I want to know how I can add
1) new R files to the package and 2) recreate the package with the new .Rd files.
I find there is no option to refresh the workspace with new files. I have been creating new packages with the new files and then copying over the R & .Rd files to the original project.
Is there a way. Do let me know
Thanks
You can create .R files manually and save them in folder called R in the main directory of your package (e.g., my-package/R).
Use roxygen2 package to create .Rd files and other documentation.
You may find helpful information how to create R packages here: R packages by Hadley Wickham
Related
I have a file work.go opened in vim-go. It's in package oldpackagename.
I want to refactor and rename it to newpackagename. Is there some tooling for that? The reason is, the initial assumptions for oldpackagename do not apply anymore.
I know I can do search and replace stuff, but usually either
GoRename resp.
nmap <leader>rn <Plug>(coc-rename)
work just fine on automatically renaming all occurrences.
But for the package name, I get:
vim-go: [rename] SUCCESS vim-go: cannot rename the identifier at the
requested position
for GoRename and:
[coc.nvim] Error on rename: The element can't be renamed.
for coc.nvim.
Is package renaming different? Do I have to use search/replace or are my configs maybe corrupted?
Under the hood, vim-go uses either gorename or gopls to run :GoRename; the default is now gopls.
Both of these don't support renaming packages:
Open issue for gopls to support package renaming
An explicit mention of "package renaming" as a TODO feature in the gorename source code
For coc.nvim, I'm not sure, but it seems to integrate with gopls, so the same lack of support would apply.
gopls should support package renaming soon (Oct. 2022).
Its integration with vim-go should take advantage of that as soon as the feature is released.
Issue 41567 mentions CL 420958
gopls/internal/lsp: add support for package renaming
Users can now rename packages by performing a rename on the package name in package declarations.
The editor will prompt user with a dialogue text field to change the package name.
This rename feature then do the following:
Rename all the external imports of the renaming package. In case there is renaming conflicts within a file, the feature repeatedly try fresh names constructed by appending new package name with number of try times so far until succeed.
Rename all the internal references to the renaming package from its files.
Rename the directory of the renamed package and update the imports' paths of any packages nested under the renamed directory.
Rename the test package with the new package name and suffix "_test" with the current test package name ends with "_test", or just the new package name otherwise.
However:
Todo:
Add a test for the case when the renaming package's path contains "internal" as a segment.
Allow edit to the whole package path not just only the last segment of the package path
Reject renaming if the renamed subpackages don't belong to the same module with the renaming package
Check the go.mod files in the workspace to see if any replace directives need to be fixed if the renaming affects the locations of any go.mod files
This question already has an answer here:
How to use an alternate go.mod file for local development?
(1 answer)
Closed 10 months ago.
I would like to know how can I build a go project using a different go.mod file. Suppose I want to build project A inside project B module using project B go.mod file without copying the files around. That means I want to use dependencies in Project B to build Project A.
Manual option
"Module files" refers to both go.mod and go.sum
Rename or move project A's module files to some temporary names / location
Copy project B's module files into project A
Edit the newly copied go.mod file in project A, and change the module name:
module github.com/x/b changes to module github.com/x/a
Build whatever you need to build in project A
Delete the active module files in project A
Restore the proper module files for project A that you renamed or moved in step 1
These steps could be automated with a shell script or batch file if you need to do it often.
With build command
Using the go help build command, we can see the build flag -modfile
-modfile file
in module aware mode, read (and possibly write) an alternate go.mod
file instead of the one in the module root directory. A file named
"go.mod" must still be present in order to determine the module root
directory, but it is not accessed. When -modfile is specified, an
alternate go.sum file is also used: its path is derived from the
-modfile flag by trimming the ".mod" extension and appending ".sum".
Using this, we can directly use an alternative set of module files to build things in project A.
First, the flag description indicates that it may write to the go.mod file, so it's probably still a good idea to create a copy of project B's module files to do this.
Second, using project B's module file is going to be a problem if: 1. project A and project B have a different module name declared in their module file, and 2. packages in project A import other packages in project A. The module name determines what the import path of packages in the module will be, so changing it could break imports.
So the best practice should still be to:
Make a copy of project B's module files
Change the module name in the copy
Then you can run the build command like this to build in project A:
go build -modfile path/to/projectb/go.mod
First, make a folder b somewhere. Then make a folder a inside b. Then make
b/b.go:
package b
const Something = 1
Then make b/a/a.go:
package a
import "b"
func something() int {
return b.Something
}
Then go back to b folder, and do go mod init b. Done.
I am trying to browse code for gVisor with VScode.
However, unlike other Go projects, gVisor is built with bazel, and the source code is not located under $GOROOT or $GOPATH. Maybe this prevents gVisor packages from being searched by VSCode go extension. Go-to-definition is not working in most cases, except for cases where the definition can be found under the same directory.
How can I setup VSCode with bazel Go projects? Especially gVisor. Thanks!
The linked gVisor rule now proxies a more canonical implementation
This setup worked for me:
In your workspace's root BUILD file you can add the following build rule
# in BUILD.bazel
load("#io_bazel_rules_go//go:def.bzl", "go_path")
go_path(
name = "gopath",
mode = "link",
deps = [
"//my/binary/here",
"//any/other/binaries/you/want/linked",
],
)
(if you don't yet have a gazelle import for the bazelbuild/go_rules, you would need to import it for bazel)
# in WORKSPACE
http_archive(
name = "io_bazel_rules_go",
sha256 = "8e968b5fcea1d2d64071872b12737bbb5514524ee5f0a4f54f5920266c261acb",
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.28.0/rules_go-v0.28.0.zip",
"https://github.com/bazelbuild/rules_go/releases/download/v0.28.0/rules_go-v0.28.0.zip",
],
)
Build this command to create a symlinked folder in your blaze-out at bazel-bin/gopath that contains links to each of your dependencies. You'll have to do this any time you add a new dependency. You will see a line for each symlink created.
bazel build :gopath
(assuming you're using VSCode with the Golang extension) Set your workspace settings for the go extension to point to this gopath. Note you'll need to have it be a worspace trusted extension in order for this to work.
// In .vscode/settings.json
{
"go.gopath": "/YOUR ABSOLUTE PATH TO YOUR WORKSPACE//bazel-bin/gopath"
}
Restart VSCode
Enjoy!
NOTE: if you have a go.mod file in your root dir, this will not work.
gVisor recently added a gopath BUILD rule that creates a canonical GOPATH tree from the source.
You may be able to use that the edit more effectively from VScode.
I'm trying to understand how to organize my golang project using go1.11 modules. I tried several options, but none of them worked.
I have some code in the main package under the application folder and a local package that the main package uses.
$GOPATH
+ src
+ application/
+ main/
+ main.go
+ otherFileUnderMainPackage.go
+ aLocalPackage/
+ someCode.go
+ someCode_test.go
+ someMoreCode.go
+ someMoreCode_test.go
Files in the main package, imports ../aLocalPackage. When I compile by go build main/*.go it's working.
Then, I ran go mod init application: V.0.9.9 and got the go.mod file, but the build always fails. I always get error about not finding the local package: build application:V0.9.9/main: cannot find module for path _/.../src/application/aLocalPackage. I also tried to place the local package right under src/, place it under main/ etc. but none of these methods worked for me.
What is the way to use modules and local packages?
Thanks.
Relative import paths are not supported in module mode. You will need to update your import statements to use a full (absolute) import path.
You should also choose a module name other than application. Your module path should generally begin with a URL prefix that you control — either your own domain name, or a unique path such as github.com/$USER/$REPO.
I had some problems working with local packages myself.
There are two tricks to make it work:
you run "go build" in the package directory
This compiles the package and places it in the build cache.
This link about code organisation in go explains more.
You can identify where the cache is using:
>go env GOCACHE
/home/<user>/.cache/go-build
Import using a path relative to the project
I puzzled loads over what the correct import path was and finally discovered that go doc or go list will tell you.
>go doc
package docs // import "tools/src/hello/docs"
>go list
tools/src/hello/docs
For example. I have a hello world API project and was using swaggo to generate documentation which it does in a docs sub-directory.
To use it I add an import:
_ "tools/src/hello/docs"
For my case the _ is important as docs is not used directly but we its init() function to be invoked.
Now in hello/main.go I can add "tools/src/hello/docs" and it will import the correct package.
The path is relative to the location of go.mod if you have one.
I have tools/ here as I have a go.mod declaring "modules tools".
Modules are a different kettle of fish - see https://github.com/golang/go/wiki/Modules.
Recent versions of go (1.11 and later) can create a go.mod file which you may use to fix the version of a module that is used and avoid go's crazy default behaviour of just downloading the latest version of any package you import.
I have written a blogpost on how to start your first Go project using modules.
https://marcofranssen.nl/start-on-your-first-golang-project/
In general it boils down to just create a new folder somewhere on your system (doesn't have to be in GOPATH).
mkdir my-project
cd my-project
go mod init github.com/you-user/my-project
This will create the go.mod file. Now you can simply create your project layout and start building whatever you like.
Maybe one of my other blogs can inspire you a bit more on how to do things.
https://marcofranssen.nl/categories/software-development/golang/
So I was developing a go application for the very first time. I came to know that there are two variables GOROOT and GOPATH which are used to maintain go packages. What I understand till now, is that GOROOT is for the go binary files and GOPATH is mainly for storing library and helper packages that is needed for projects.
Here is my current project structure -
/Users/john/work/project-mars
/Users/john/work/project-mars/main.go
/Users/john/work/project-mars/helper
/Users/john/work/project-mars/helper/helper.go
Content of main.go
package main
import (
"fmt"
"helper"
)
func main(){
fmt.Println("Hello")
}
Content of helper.go
package helper
import (
"fmt"
)
func SayWorld(){
fmt.Println("World")
}
And the go variables are -
GOROOT = /Users/john/apps/go
GOPATH = /Users/john/apps/go-packages
Problem:
Now when I perform the following command, I get this error -
mac-machine:project-mars john$ go build main.go
main.go:5:5: cannot find package "helper" in any of:
/Users/john/apps/go/src/helper (from $GOROOT)
/Users/john/apps/go-packages/src/helper (from $GOPATH)
I understand that GOPATH should be the project directory that I am working on. But I am concerned with keeping my projects and library packages in a modular way, so that when later I have a totally different project (i.e. project-aurora) which might use same github helper packages, that they are not downloaded two times, both in project-mars and project-aurora .
How can I avoid this redundancy while working on different projects ?
Update: It's not that I can not compile them. I can use the GOPATH as my project directory and use src,pkg,bin project layouts and also reorganize the files and finally get to compile the project. yeeeeppi. But my question is about resolving the redundancy of common package problem that appears in this single GOPATH way.
Please read How to Write Go Code carefully. It explains everything you need to know.
You don't use GOPATH as your project directory. Assuming you want to work with the standard Go tooling, your package source needs to be in the directory corresponding to its import path, just like any other package.
Your project should be located at $GOPATH/src/project-mars, which can be built via go install project-mars. The helper package should be located at $GOPATH/src/project-mars/helper, and imported via "project-mars/helper".
Rename your helper-lib folder to helper
Then move this folder from project-mars to the upper folder work
This should make your
import "helper"
statement in main.go work.