I recently jumped back into an old Go project and migrated it to the vendor approach, using dep
It completed sucessfully and I now have a bunch of libs in the local projects vendor/ directory. Great!
However, I now want to work on one of those vendored libs, and see the changes in my main app live. The lib exists in its own project of course, doesn't live its life in this other apps vendor folder - and other local projects should be able to see the live changes too if necessary.
I'm thinking something like npm link, to compare across ecosystems.
How is this typically managed in Go?
Related
How do you work in team on react native projects?
I'm working in Team of 2 people and having a lot of issues with working on the same project.
I don't understand how to properly create an environment so we can sync our code between each other while working on the same project. Now, we create a git repo with /ios and /android folders, but the thing is: the /ios folder always needs to be changed, because it links to the computer that was last building the project.
For example: we are working at the same time on different .js files and add a new npm dependency and we wish to sync our changes, so we commit changes to the Git repo and try to sync, this is where our pains begin.
The one need downloading the changed has to go to Xcode and manually update all the Framework Search Paths, Header Search Paths, delete libraries that Xcode doesn't see and then add them again.
I know it's moreof an Xcode problem, but I didn't see any detailed guide about team syncing in projects. I know that at Facebook people are doing a lot of cooperative work and I'd appreciate some input over our issues!
If you are using git, you can configure your .gitignore-file to prevent committing xcode-specific stuff and other configuration files.
I can highly recommend gitignore.io, which is a "web service designed to help you create .gitignore files for your Git repositories" [Source].
You can for example type in XCode (or AndroidStudio, ReactNative, Gradle, etc.) and it will automagically generate a .gitignore file for you.
We currently are using govendor to manage packages in our go repository. Since we are using a lot of packages, we have decided to check-in the packages sources code into vendor folder, so that:
Saving time downloading all packages every time the repository needs to be built in build machines.
Avoiding the possibility of one package becoming unavailable online (being deleted, network issues, etc...)
I am interested to use the modules notion introduced in v1.11. However I can't seem to find a similar approach of check-ing in the packages instead of having to download all the packages.
Any ideas?
Go modules provide a go mod vendor command that will create a vendor directory in your package root, same as glide or govendor or dep do.
I'm new to Golang. As I understand, when you want to create a new Go project, we just need to create a directory. Then we point the environment variable GOPATH to this directory. Inside this directory, we create three subdirectories pkg, src and bin. Then when we execute go get ..., the third-party package will be installed in the pkg subdirectory. Later if I want to create another Go project, I create a new dir called project2 and point GOPATH to project2. At this time go get ... will download third-party package in the pkg subdirectory of project2. My question is, whether Go has a central repository? If not, the same package will be downloaded twice if they are used in two different projects. Is that true?
I guess now there is https://gocenter.jfrog.com/
More info in this blog https://jfrog.com/blog/go-at-full-speed-with-gocenter
There is no central repository of go packages. Go always is looking for packages either in GOPATH or GOROOT. go get simply downloads packages using git or mercurial. I recommend you to read
https://golang.org/doc/code.html
and https://peter.bourgon.org/go-best-practices-2016/#repository-structure
GOPATH simply tells go compiler where to search for src, pkg directories.
Later if I want to create another Go project, I create a new dir called project2 and point GOPATH to project2
…
My question is, whether Go has a central repository? If not, the same package will be downloaded twice if they are used in two different projects. Is that true?
No, there is no central repository for Go code. However, it is also not true that the packages will always be downloaded twice.
The misconception here is that GOPATH points to an individual project: it does not. Instead, GOPATH points to an environment where all of your packages live; it is where go get will download packages, and where go build will look for packages when building.
Instead of changing GOPATH for every project, you should set GOPATH once and put all of your projects in $GOPATH/src/ (your projects don't contain an src/ directory, they go in the src/ directory).
So for example, the entire tree might look like:
$GOPATH/src/bitbucket.org/ (or GitHub, or your website, or whatever)
├── YourProject
└── AnotherProject
Update
It is worth noting that this answer is no longer correct. Now that Go Modules are the normal versioning mechanism for Go code and $GOPATH is being phased out, a central proxy has been setup that routes all requests for packages through Google servers where the various tagged versions of the package can be cached. A separate checksum database keeps hashes for every package that are audit-able and can help you detect if a package author has changed an already released tag. All of this isn't a central repository in the same sense that PyPi (in the Python world) or NPM (for JavaScript) are a repo: the packages are still fetched from their source control, but because all packages are routed through the proxy by default it serves a similar purpose. For more information see https://proxy.golang.org/
Recently, a new site that collects information about Go packages has emerged:
https://go.dev/.
go.dev is the hub for Go users providing centralized and curated resources from across the Go ecosystem.
It is an official companion website to golang.org. It does not qualify for a repository, such as cpan, nmpjs, nuget or crates. For external packages, it simply links to their respective Github pages.
Go.dev is currently in MVP status. We’re proud of what we’ve built and excited to share it with the community. We hope you find value and joy in using go.dev. Go.dev only has a small portion of features we intend to build, and we are actively seeking feedback
But as is written it the about page, it is still in early development. Maybe one day (hopefully) it shall become a fully featured code repository.
According to the Go documentation they would like you to have a workspace that you should put all their projects in.1 However, as far as I can tell, this all falls apart as soon as you want to make a project that does not use Go exclusively.
Take a project where it is made up of many micoservices for example. Lets say that it is structured like this:
app/
authentication/ (Using rust)
users/ (Using NodeJS)
posts/ (Using Go)
Only one part of the app would be written in Go, and that part is nested in a subdirectory of the app. How would I apply the Go workspace philosophy to this situation?
https://golang.org/doc/code.html#Workspaces
Using a different GOPATH per project is a very good and simple approach. In my experience this also works better than vendor since you can also install binaries and keep them on different versions.
vg is a simple tool that helps managing workspaces, it integrates with your shell and detects automatically workspaces when you cd them.
Disclaimer: I am one of the authors of the tool.
As of Go 1.11, go now has modules. Amongst other things, modules enable you to have isolated source trees (with any number of packages and their own dependencies) outside of your $GOPATH.
You create a new module by running go mod init <module name> (you must be outside of $GOPATH/src to do this). This will create a go.mod file in the current folder, and any go command you run in that folder (or any folder beneath) will use that folder as your project root.
You can read more about using go modules as workspaces in this post: https://aliceh75.github.io/using-modules-for-workspaces-in-golang (disclaimer: I wrote it), and you can read more about Go modules on the Go Modules Wiki:
https://github.com/golang/go/wiki/Modules
You can put app/ in $GOPATH/src. Then whenever you're ready to build, you specify the path of your source files, relative to where they are in GOPATH.
For example:
if your app source is in $GOPATH/src/app/ and your .go files are in $GOPATH/src/app/posts/ then you can build a source (lets say posts.go in app/posts/) with go build $GOPATH/src/app/posts/posts.go or better go build posts/posts.go with app/ as your current working directory.
just set GOPATH according to your go files:
GOPATH=$PROJECT_PATH/app/posts
then put your source codes under
$PROJECT_PATH/app/posts/src/package
I use Team Foundation Server for source control. All of my projects use a structure that have dev, main, and release branches.
For the purposes of this question, I have 2 TFS projects, one is my application and the other is a shared library. The solution file for my application includes the shared library project (even though it is in a separate TFS project) because it makes it easier to debug. So I have a solution in 1 TFS project pointing to a project in another one.
The problem I'm running into relates to branches. What I'd like to do is point to the dev branch version of the shared library when in the dev branch of my application's solution. Similarly I want the main branch version of my solution to point to the shared library in the main branch, etc.
Does anyone have ideas of how to handle this?
I can't tell you if this is the best way, but I'm pretty sure it will work if you don't come up with anything better.
Create a symbolic link between the two directories, and map the project using that.
Add a pre-event MSBuild script to delete and recreate the symbolic link for each build based on the current branch. For example:
rmdir MyProject
mklink /d MyProject c:\dev\Main\MyProject
You'll probably want to put this in a batch file and call that.