3

How can I use a development copy/clone of a package while using dep and a vendor directory? The vendor directory is included in the main repository.

For example, I have forked package and replaced it with my own on github. I want to be able to edit the code and not have to git push + dep ensure for each change of the package.

If I clone the package in the vendor directory, it I won't be able to commit that directory into the main repo because it's treated as a separate repository.

I tried a trick to .gitignore the .git directory from outside the package. This works well until dep ensure is run, where the .git directory is nuked.

gak
  • 32,061
  • 28
  • 119
  • 154

2 Answers2

2

According to the dep docs, there is no inbuilt way of doing this as it stands.

They also recommend not modifying packages in the vendor directory directly, for the reasons I discovered: it gets nuked when running dep ensure.

Their main suggestion is to manually remove the package from the vendor/ directory, modify it in the regular $GOPATH, and running dep ensure -update <pkg> when finished development of it.

This is sufficiently better than pushing for each change, but still requires to manually push/dep ensure when completing the development work.

gak
  • 32,061
  • 28
  • 119
  • 154
1

An alternative to "ignoring .git" is to keep the .git folder elsewhere! (well outside of your Go project)

Any time you need to execute a git command in the vendored sub-project, you would need to use an alias to the git command, which would be:

alias gg='git --git-dir=/path/to/elsewhere/.git --work-tree=/path/to/vendored/subproject'
# Windows
doskey gg=git --git-dir=C:\path\to\elsewhere\.git --work-tree=C:\path\to\vendored\subproject $*

That way, you can still benefit from version-controled operations within your vendored subproject.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for the suggestion. It is a novel approach, but slightly hacky in my opinion. I will continue working out a cleaner approach. – gak Dec 31 '17 at 08:15
  • @GeraldKaszuba I would argue it is not "hacky", and promote a clean separation of Golang dependency management on one side, and source control management on the other. – VonC Dec 31 '17 at 08:17