3 ms·

I took a quick look at your main.go file and have a suggestion. I strongly recommend against using external dependencies (e.g. bitbucket.org/howeyc/fsnotify) f

by jff 13y ago

I took a quick look at your main.go file and have a suggestion. I strongly recommend against using external dependencies (e.g. bitbucket.org/howeyc/fsnotify) for something important. It's fine for development, but if "howeyc" decides he's sick of bitbucket and deletes his account, you're now screwed. If you want to use "go get" to install Hugo, make forks of the external dependencies. bitbucket.org/spf13/fsnotify and what not. You can then keep those updated at your own pace, rather than waking up to see that someone has changed their API and your code no longer compiles. Remember the game "Haunts"? IIRC this was one of their problems--they failed to manage dependencies appropriately and got into major hell. Many C and C++ programs ship source to external libraries along with their own source for this exact reason. We've taken to doing the same. Here's what Brian Fitzpatrick has to say about "go get": "Go get is nice, for you know, playing around, but if you're doing something serious and you're going to deploy binaries to production, your deploy to production script should not involve fetching some random dude's stuff on Github" We have taken to making a go "workspace" in our repos, with a bash script at the top level and a src/ directory containing all the libraries and such we've written. The bash script sets GOPATH and compiles everything in src/. It's quick and you avoid dependency hell.

spf13 13y ago
Great idea. That will make a lot of things easier. A lot of people struggle with obtaining the right dependencies as many people don't already have mercurial and bazaar.
- jff 13y ago
  It puts a bit more work on you, since you have to track the dependencies, but it'll pay off the first time somebody decides to check in a radical API overhaul; you'll be able to update your code on your own schedule, not in a panicked rush because bug reports are flooding in. It also makes things easier if you decide to modify the libraries, or if the author abandons his code and someone else becomes the "canonical" source. Your code will just import "fsnotify", and you can put whatever source you prefer in $GOPATH/src/fsnotify/
irahul 13y ago
> I strongly recommend against using external dependencies (e.g. bitbucket.org/howeyc/fsnotify) for something important. It's fine for development, but if "howeyc" decides he's sick of bitbucket and deletes his account, you're now screwed. How? When you `go get` a package, it physically becomes part of your repository. If "howeyc" deletes his account, it doesn't affect the copy checked out under my repository. Unless you go out of your way to exclude the `go get` packages from getting checked in, you are safe.
- jff 13y ago
  When you 'go get github.com/spf13/hugo', it checks out a copy into $GOPATH/src/github.com/spf13/hugo. It then fetches all the external dependencies listed in hugo's source and fetches them, so you'll get $GOPATH/src/bitbucket.org/howeyc/fsnotify etc. Those exist in your own local tree, but if howeyc deletes his repository and somebody new tries to check out hugo, he'll get an error when "go get" fails to find bitbucket.org/howeyc/fsnotify. Now, what you as the developer can do, as I mentioned in my original post, is get all the packages you need and put them in a $GOPATH directory, so you have $GOPATH/src/hugo and $GOPATH/src/fsnotify etc., then check in the entire $GOPATH directory. Your code then imports "fsnotify" rather than "bitbucket.org/howeyc/fsnotify" and so on. This repository is no longer trivially fetchable+compileable with "go get", but in my opinion that's a small price to pay--and compilation is still very simple.

by jff 13y ago

spf13 13y ago

Great idea. That will make a lot of things easier. A lot of people struggle with obtaining the right dependencies as many people don't already have mercurial and bazaar.

jff 13y ago
It puts a bit more work on you, since you have to track the dependencies, but it'll pay off the first time somebody decides to check in a radical API overhaul; you'll be able to update your code on your own schedule, not in a panicked rush because bug reports are flooding in. It also makes things easier if you decide to modify the libraries, or if the author abandons his code and someone else becomes the "canonical" source. Your code will just import "fsnotify", and you can put whatever source you prefer in $GOPATH/src/fsnotify/

irahul 13y ago

> I strongly recommend against using external dependencies (e.g. bitbucket.org/howeyc/fsnotify) for something important. It's fine for development, but if "howeyc" decides he's sick of bitbucket and deletes his account, you're now screwed. How? When you `go get` a package, it physically becomes part of your repository. If "howeyc" deletes his account, it doesn't affect the copy checked out under my repository. Unless you go out of your way to exclude the `go get` packages from getting checked in, you are safe.

jff 13y ago
When you 'go get github.com/spf13/hugo', it checks out a copy into $GOPATH/src/github.com/spf13/hugo. It then fetches all the external dependencies listed in hugo's source and fetches them, so you'll get $GOPATH/src/bitbucket.org/howeyc/fsnotify etc. Those exist in your own local tree, but if howeyc deletes his repository and somebody new tries to check out hugo, he'll get an error when "go get" fails to find bitbucket.org/howeyc/fsnotify. Now, what you as the developer can do, as I mentioned in my original post, is get all the packages you need and put them in a $GOPATH directory, so you have $GOPATH/src/hugo and $GOPATH/src/fsnotify etc., then check in the entire $GOPATH directory. Your code then imports "fsnotify" rather than "bitbucket.org/howeyc/fsnotify" and so on. This repository is no longer trivially fetchable+compileable with "go get", but in my opinion that's a small price to pay--and compilation is still very simple.