I want to search in the go pkg go-git.
ctrl+shift+f searches only in my module.
Probably this will not directly answer, but it's an workaround, that I personally prefer:
Hovering over a function, that is from a foreign package, VS Code shows the godoc description. There is always a link to pkg.go.dev (This link is for the PlainClone example):
Following it you are redirected directly to GO's package website.
Here is already a nice list with the module's functions.
if you want to dive deeper:
On the top of the repository there is the link to the repo host.
Experiences show, that this is mostly Github. While GitHub's search used to be proscribed, it can nowadays be a mightful tool:
https://docs.github.com/en/search-github/searching-on-github/searching-code#search-within-a-users-or-organizations-repositories
Again I mention that is very subjective, but GO's complex way of storing modules locally with it's many env variables and stuff made me feel using the internet is more comfortable =)
Related
godoc has been removed from the go standard install since 1.12 and looks like it wont be updated anytime soon. pkg.go.dev at least appears to be its successor. It also has additional documentation features like grabbing the README.md file and rendering it in the documentation page.
For these reasons I was hoping to switch over to using pkg.go.dev locally to view and create documentation for small internal packages. The major issue is that unlike godoc there does not seem to be a clear usage guide. I also do not know if pkpg.go.dev is completely overkill for this task. So I would like to know:
Can and should pkg.go.dev be used as a local godoc replacement?
If yes, how would I run it for this task?
Run pkgsite locally.
go install golang.org/x/pkgsite/cmd/pkgsite#latest && pkgsite
References:
https://tip.golang.org/doc/comment
https://pkg.go.dev/golang.org/x/pkgsite/cmd/pkgsite
You can use the x/tools/godoc that has the previous godoc tool
Running godoc [1] on its own worked for me, but was really slow because it generates docs for every single package in the standard library, while I only care about the local package that I am working on. To that end, if your package is in a folder called something, you can move the folder so that it looks like this:
godoc/src/something
Then, go to the godoc folder, and run
godoc -goroot .
Then, browse to localhost:6060. Alternatively, another site is available for
Go docs [2].
https://github.com/golang/tools/tree/master/cmd/godoc
https://godocs.io
My GOROOT path :-
C:\Go
I have set GOPATH to :-
C:\Users\kunal\go
But when I import modules (like github.com/gorilla/mux) inside VS Code. VS Code prompts me this error :-
could not import github.com/gorilla/mux (cannot find package "github.com/gorilla/mux" in any of C:\Go\src\github.com\gorilla\mux (from $GOROOT) C\src\github.com\gorilla\mux (from $GOPATH) \Users\kunal\go\src\github.com\gorilla\mux (from $GOPATH))
From above It is clear that it shows me two different GOPATH which I haven’t set. How do I fix this?
I recommend going through the following path, using official documentation pages:
Read about properly installing Go for your platform
Read the getting started tutorial which also tells you how to install 3rd-party packages and use them in your code.
It should take you no more than 20 minutes to go through these steps, and it's almost certain that you'll be able to accomplish your goal by the end of the process. As a bonus, keep going through the Getting Started guide beyond the first page to learn how to create your own Go modules, use them from other modules, write tests, build your code into a binary, and more.
This is IMHO the minimal background required to even try writing Go programs; without going through these steps, you will lack crucial fundamental understanding and it will be hard to even understand SO answers.
Specifically in your case - please remember that at this time (with Go 1.16), GOPATH is pretty much deprecated and you should be using Go modules instead. The documents linked to above will explain this in detail.
I ll give a TLDR for the solution given by #Eli Bendersky. If you don't understand GOPATH and go modules, you can look it up yourself here. Here I have assumed you are using VS Code with golang extension. I haven't tested it for other IDEs but it should work in a similiar way.
In the source directory where you have the main.go, create a file named go.mod
Name the package name to whatever you like and save the file.
go to your terminal and run go build main.go, this will download all the missing packages(if any) and will update the go.mod file and create a new file go.sum to create the checksums of the package versions.
All the package error squiggles should be gone by now in your IDE, if it doesn't try restarting your IDE once. You are good to go!
If you are stuck somewhere, let me know in the comments.
I just started to learn golang today. But it seems that I understood more from what these experts are trying to say when trying to answer this basic question.
I don't claim deep knowledge of golang. But as a 2100 rated chess player, I do claim common sense and rigorous thought process. The GOPATH environment variable is very much in use do not believe these kids. Only a kid would make such claims that GOPATH has no use.
The way I see it is that, the go.mod and go.sum plays in tandem with GOPATH.
Continue on your own journey, little tiger. I upvoted your question for moral support.
I am currently working on a Jekyll blog on Linux. However I'd like to add contributors to this blog who are using Windows and who haven't any skills in programming or using tools like Git etc.
I was wondering what could be the best process/pratice to enable them to post on the blog?
Installing them the entire environment and writing a script maybe?
Could it cause any issues due to the OS?
Any suggestions or advices are welcome :)
I don't think installing git, and pushing content to your repo is hard task for any non-tech guy.
1: Little tough way
Use team viewer and help your partner to setup git.
Allowed access to your repository.
Teach them, about frontmatter, and some jekyll commands.
2: Simple and smooth way.
Just get doc files dirctly from partner, which contain only content, nothing else, and convert yourself into markdown with manual frontmatter.
3: Create your own dashboard.
You can create your own dashoard like WordPress, where your partner can add categories, tags, title, meta description etc things, that can convert into frontmatter automatically. For that, you need to build yourself. (I find out that kind of generator here, but look's like he deleted, you can find it, by visiting him, old deleted commits).
I had the same problem so I ended up using Wordpress as the interface to it and creating a plugin to marry the systems up.
I figured I'd share it so feel free to have a look:
https://wordpress.org/plugins/wp2jekyll/
I got several Go projects which is documented compatibly with godoc. We use godoc to share doc and code internally as a doc server without significant problem. However we need more control on opening code when we want to share doc with 3rd party. Is there a way to run godoc in a special mode that showing types and docs but never link to or showing source code?
I've tried
godoc -http=0.0.0.0:8090 -links=false -src=false
but not working, still can link to type definition code. Just wondering if missed sth. Go version, 1.3.
The src file only refers to command line mode, not to server mode, so it won't help you. The way I see it there are a few options:
Rewrite godoc for your needs and use your own fork.
Don't use the server mode, render the docs in command line mode and just create a server out of that.
Better yet (I'm not entirely sure 2 will work) - rewrite the templates a bit so the source code won't be linked. But you'll still need to make sure people who enter the path manually won't see the code so it will require fudging the source templates as well. or...
Maybe the simplest thing - run it behind nginx or a similar reverse proxy, and make sure the /src path in the server is closed to outside visitors, or password protected or whatever. That way your internal team can still use it.
Personally I'd go with 4, it's a couple minutes of work and will be the most robust and flexible solution.
If your writing a go command (not a package) that is large how do you layout its internals? I would love to have some utility packages etc but not have those exposed for anything except the command's code. If it's all in the same repo I don't see whats stopping someone from importing those internal use packages.
You might make your utility packages internal to your package — like this. This won't prevent anyone from using them but a) why would you care anyway? b) the package's structure would give a clear hint on that these "subpackages" are internal to the project.
The answer is simple (but most probably not what you'd like to hear): Do whatever you like and is allowed. Having utility packages living somewhere is perfectly fine, either in the same repo as a "sub-package" or in a different repo.
Regarding
I don't see whats stopping someone from importing those internal use packages
Why do you care? If the packages encapsulate distinct and usable functionalities someone might benefit from importing them. Keeping those function together with the command does not "protect" them in the sense of "nobody should be able to look at my code". Just make it clear in the docs that you'll feel free to do incompatible changes at any time. Go is not about preventing each and any stupidity and protecting the lazy and incapable ones who deliberately ignore any documentation from shooting their foot.