Leiningen offers the ability to add a project to the local repository, the help text is:
> lein help install
Install jar and pom to the local repository; typically ~/.m2.
Cautious of making a mess while experimenting, is there a way within Leiningen of managing the local repository? And removing packages installed by mistake?
For Maven, I did find this question and answer - which suggests deleting files, is that the best way? (And anything to be careful of if deleting manually?)
Just delete the relevant files under ~/.m2; there's nothing to fear... (but fear itself)
Lein uses ~/.m2 for storing all dependencies locally
Related
I build a binary file for a GitHub repo (go code), which works fine. no issues.
I forked that repo, and modified a single line in the HTML file that has nothing to do with GO code, built the binary file for the new forked repo but the binary it generates refers to the original repo code, can't understand why.
I even cleaned all the code using go clean -i all command and manually removed all the installed code, binary files from $home/go/bin and the repo directory, but it still refers to the original repo code instead of new forked code.
Based on the solution suggested by Tobias, I performed the following steps:
After that, I executed go build in that repo directory, but the new binary file still refers to the old code. I even removed the old binary file and generated a new one.
That's a common problem in go. The references system in "location based" so it searches for these files in the "correct" path. Idk if go modules fix this issue, but atleast when not using go modules you'll have to work around it.
You can solve it by
Solution 1
Download the original repository you forked by:
go get http://github.com/awesome-org/tool
Add your fork as remote
git remote add awesome-you-fork http://github.com/awesome-you/tool
You'll have to make changes in the folder of the original downloaded repo and Push and Pull to/from your fork.
git pull --rebase awesome-you-fork
git push awesome-you-fork
Solution 2
Work around go get:
You create the path the original repo would have, but clone your own fork into it. That way you can push & pull to your fork. That may be the better solution
cd $GOPATH
mkdir -p {src,bin,pkg}
mkdir -p src/github.com/awesome-org/
cd src/github.com/awesome-org/
git clone git#github.com:awesome-you/tool.git # OR: git clone https://github.com/awesome-you/tool.git
cd tool/
go get ./...
These Solutions were found here: http://code.openark.org/blog/development/forking-golang-repositories-on-github-and-managing-the-import-path
The problem with a forked copy of a go packages is when the package is really multiple go packages in one repo, the import statements refer to original base repo, ie: github.com/orig/repo.
This is not an issue for repos with only one go package as it never refers to itself.
But if it has multiple, ie: package github.com/orig/repo/A imports github.com/orig/repo/B
And then you fork it as: github.com/fork/repo
Then when the go compiler sees import "github.com/orig/repo/B" in the source, it goes to download the original version and not your fork.
Fortunately, go modules solves this.
Basically, create a go.mod at the top of your forked repo and add:
module github.com/orig/repo
then, the go compiler will assume that you are "orig/repo" regardless of where you actually are checked out from.
so, when orig/repo/A imports orig/repo/B, it will look locally.
If there are other imports you need to override that are outside the main forked repo, you can also force dependencies to come from another place using replace
SOLVED
At first I thought it was problem with a FORK (which is a common problem experienced with fork of Go language repo's), but it turns out, it was Repo specific problem.
One of the dependent libraries had to be reinstalled for the forked repo to work, which was not mentioned in the Original repo docs.
Finally, this link helped: https://github.com/inconshreveable/ngrok/issues/181#issuecomment-65646229, the problem was not generic but repo specific
I followed the below steps from above link to resolve the dependency on go-bindata
go get github.com/jteeuwen/go-bindata
cd $GOPATH/src/github.com/jteeuwen/go-bindata/go-bindata
go build
I have an app hosted in Heroku, and I use glide to collect dependencies when deploying the app. The problem is that I have one library, namely, gonum.org/v1/gonum, that cannot be downloaded the standard way. Is it possible to somehow force glide to use pre-downloaded version of package instead?
If you are vendoring your dependencies before deploying to heroku, you should be able to place the pre-downloaded version of the dependency directly in the vendor folder instead.
Glide also support repo (see the documentation) which allows you to tell glide which repo to find the code in. You could push the code to a private (or public) github repo and configure your glide.yaml file to point at that repo.
First I have read this answer: Vendoring in Go 1.6, then I use it as my example.
My gopath is GOPATH="/Users/thinkerou/xyz/", and the follow like:
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/ou$ pwd
/Users/baidu/xyz/src/ou
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/ou$ ls
main.go vendor
Now, I use go get, then becomes this:
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/ou$ ls
main.go vendor
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/ou$ cd vendor/
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/ou/vendor$ ls
vendor.json
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/ou/vendor$ cd ../..
thinkerou#MacBook-Pro-thinkerou:~/xyz/src$ ls
github.com ou
thinkerou#MacBook-Pro-thinkerou:~/xyz/src$ cd github.com/
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/github.com$ ls
zenazn
vendor.json is this:
{
"comment": "",
"package": [
{
"path": "github.com/zenazn/goji"
}
]
}
then, I should use what commands? why have no use vendor? My go version is 1.6.2.
With Go1.6, vendoring is built in as you read. What does this mean? Only one thing to keep in mind:
When using the go tools such as go build or go run, they first check to see if the dependencies are located in ./vendor/. If so, use it. If not, revert to the $GOPATH/src/ directory.
The actual "lookup paths" in Go 1.6 are, in order:
./vendor/github.com/zenazn/goji
$GOPATH/src/github.com/zenazn/goji
$GOROOT/src/github.com/zenazn/goji
With that said, go get will continue to install into you $GOPATH/src; and, go install will install into $GOPATH/bin for binaries or $GOPATH/pkg for package caching.
So, how do I use ./vendor?!?!
Hehe, armed with the knowledge above, it's pretty simple:
mkdir -p $GOPATH/src/ou/vendor/github.com/zenazn/goji
cp -r $GOPATH/src/github.com/zenazn/goji/ $GOPATH/src/ou/vendor/github.com/zenazn/goji
In short, to use vendoring, you copy the files using the same github.com/zenazn/goji full path, into your vendor director.
Now, the go build/install/run tooling will see and use your vendor folder.
An easier way instead of copying everything manually
Instead of finding and copying all 25+ vendor items, managing their versions, updating other projects etc... It would be better to use a dependency management tool. There are many out there and a little googling will point to you several.
Let me mention two that works with the vendor folder and doesn't fight you:
godep
govendor
In short, these tools will inspect your ou code, find the remote dependencies, and copy them from your $GOPATH/src to your $GOPATH/src/ou/vendor directory (actually, whatever current directory you are in when you run them).
For example, say you have all of your dependencies installed and working normally in your $GOPATH/src/ou/ project using the normal GOPATH/src/github installation of your dependencies. Your project runs and your tests validate everything is working with the exact version of the repos you have. With Godep as an example, you'd run this from your project root folder $GOPATH/src/ou/:
godep save ./...
This would copy all dependencies your project uses into your ./vendor folder.
Godep is by far and large the most popular. They have their own Slack channel on the Gopher Slack group. And, it's the one I use on my teams.
Govendor is another alternative I read has a nice sync feature. I haven't used it though.
Over Usage of Dependency Management Tool
This is purely opinion, and I'm sure haters will downvote... But as I need to finish my blog post on the subject, let me mention here that most people worry too much about depdency management in Go.
Yes, there is a need to lock in a repo to a version you depend on so you can ensure your system builds in production. Yes there is a need to ensure no breaking changes to a way a dependency is interrupting something.
Use dependency management for those, absolutely.
But, there is overuse of simple projects that lock in huge amounts of dependencies when in reality...
You may only need to lock in only 1 dependencies; otherwise, you want the latest version of MySQL drivers and test assertion frameworks for bug fixes.
This is where using the ./vendor/ folder apart from dependency managrment tools can really shine: you'd only need to copy that repo that need you lock in.
You selectively pick the one misbehaving repo and put it into your ./vendor/ folder. By doing this, you are telling your consumers:
Hey, this one repo needs to be held back at this revision. All others are fine and use the latest of those and update often with go get -u ./...; but, this one failed with newer versions so don't upgrade this one repo.
But if blanketly saving all your dependencies with a dependency management tool, you are basically telling your consumers:
There may or may not be a problem with one or more repos out of the 20 in the vendor folder. You may or may not be able to update them. You may or may not be able to get the latest MySQL driver. We simply don't know which may or may not be causing problems and just locked in something that worked at the time that I ran godep save. So yeah, upgrade at your own risk.
Personally, I have ran into this several times. A dependency was updated with a breaking change, and we have dozens of repos dependent on it. Vendoring just that one repo in /vendor allows us to use that one version of dependency, while go get ./... continues to run normally for all other repos to get the latest. We run with the latest bug fixes in PSQL and MySQL and others (there are constant fixes for these!) and so on.
I am working on a project that requires some dependencies. I am a little confused by the best practices regarding vendoring. Currently I am using GO15VENDOREXPERIMENT and have copied the dependencies into the vendor directory.
https://github.com/jeffellin/machine-cloudformation/tree/master/vendor/github.com
When I need to update the dependencies I checkout the source code manually from docker-machine and copy it into my vendor directory. This brings in a lot of unnecessary code, tests, etc. Is there any recommendations on automating this? I am used to maven where I can just specify version info in a configuration file.
What about GODEPS? How does that play into the GO15VENDOREXPERIMENT. I would prefer a solution where I don't have to checkin dependencies into my source tree.
There are a few tools that help with vendoring your dependencies. Most of them are able to handle GO15VENDOREXPERIMENT.
For example:
godep
glide
When I do composer install on the production system, should I use the flag --prefer-dist?
--no-dev is recommended, since it prevents the installation of packages that are only needed during development. But what is with --prefer-dist? This flag makes that the installed packages are without VCS stuff, as I read in this answer. I assume that I don't need this on a production machine. Am I right?
The dist file (e.g. tar archive) is usually quicker to download than cloning the repository (which is the case when using --prefer-source).
The main difference is that cloning the repository will give you everything, while a lib maintainer can create the dist itself. This means that they might not include the tests in the dist file for instance. That's why people suggest using --prefer-dist, as it might end up downloading less files.
Anyway, --prefer-dist isn't really needed as Composer always defaults to the dist file when downloading a stable dependency. As it's really a bad practice to have unstable dependencies running in production, you probably end up downloading the dist for all packages anyway (unless you use --prefer-source of course).