For consideration: allow functioning .git repos for packages as part of the /vendor/ folder.

[Aaron3]

Currently, go dep owns the /vendor/ directory and assumes that anything in the vendor directory is 3rd-party. The docs double down on this stating:

If you need to modify a dependency, fork it and do it properly.

However, I would argue for internal shared packages, this actually becomes quite difficult to manage.

Let's say we have:

• ProjectA
• ProjectB

Both depend on "internal/shared-db-interface."

The "Fork it" work flow looks like this:

1. Create a branch of our interface
2. Create a branch of ProjectA
3. Create a branch of ProjectB
4. In a vacuum, write code and tests for our db-interface
5. push code that may or may not work
6. go dep update ProjectA
7. update to use changes to db-interface
8. test updates
9. find there is an issue (something business logic related not a code error that could have been caught in testing)
10. switch back to db-interface
11. repeat steps 5 - 8 until no issues exist
12. switch to ProjectB and repeat steps 6 - 11 until no issues exist
13. merge our interface, finally go dep update in ProjectA and ProjectB
14. merge ProjectA and B
15. deploy

The allow .git repos looks like:

1. Create a branch of our interface
2. Create a branch of ProjectA
3. Create a branch of ProjectB
4. in the /vendor/ folder for ProjectA switch to the correct branch of the interface
5. write new code and simultaneously test in ProjectA
6. push all working code
7. switch interface branch in project B and test
8. maybe find an issue, fix and push changes
9. git pull in our interface for project A
10. test to confirm nothing new broke.
11. merge our interface, finally go dep update in ProjectA and ProjectB
12. merge ProjectA and B
13. deploy

What we do is this:

We currently handle this by adding tooling to glide that automatically turns all of our internal projects into git repos and handles some of the updating for us.

1. If the dependency is just a folder, get the actual dependency branch/commit from the glide.lock file and ensure that any changes already made are saved.
2. If the dependency is a .git repo, offer to stash any changes or to abort if something has been changed.

What are the changes needed

1. Allow retaining the .git folder or make it easy to instantiate.
2. When running update, if the dependency is an active .git repo, interactively offer the chance to git stash or cancel the update
3. Prefer using native git commands when updating a .git repo.

Final thoughts

Now I expect to hear lots of good arguments about the proper "go" way to do things; however, at the very least, I would like the maintainers to keep a similar workflow in mind and structure the go dep code knowing that there are valid workflows that make the following advice nearly impossible to follow:

If you need to modify a dependency, fork it and do it properly.

Our infrastructure has nearly a dozen different binaries and we have over a dozen of these shared packages across ranging from simple things like models and CLI tools to standard interfaces for our microservice architecture to forks of very popular packages that are missing features we need.

While they are fairly independent, they have no real use without the main projects that use them, so it's not like publishing a generic mgo or prompt-ui package. Any changes in the subpackages are because of a feature or bug that is revealed in the main projects. Adding a feature to a binary messaging package between microservices becomes non trivial when you have to fork and go dep update for every single change to the package in every single project.

Therefore, if this ability is not made part of go dep then at the very least, we need a way to modify the way go dep works for us, this could be as simple as ensuring more of the helpers in commands like ensure are public for example, then we our internal tooling could use go dep as a package and then just modify the logic of just the Run command with just a couple custom if statements for our own packages or by adding custom error conditions, but otherwise, use go dep the way it is meant to be.

Yes, forking go dep is totally possible, but maintaining a forked version of a core tool is a non-trivial task.

[mattayes]

Hey @Aaron3, thanks for posting. I believe this may be a duplicate of #935, or at least very similar. Am I understanding your use case/proposal correctly?

If not, I recommend sharing this proposal with the Gophers Slack #vendor channel. There's plenty of awesome people there who would be interested in discussing this. Here's an invite if you need it.

[mvdan]

Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!