That's somewhat the intent in enabling the timestamping of packages especially wrt. library-vendored package. Flattening dependencies will still be needed but it would be simply a matter of switching a package to the latest package release that a package may have vendored.
But again, I would not build a solution by strictly imitating vcs or other package managers from a methodology point of view. They do not handle packages the same so the solution has to be different. I firmly believe that the current assumptions held by Go tooling can help us find a quite simple(r) solution (than already exists for other languages). On Tuesday, August 2, 2016 at 6:17:35 AM UTC+2, Lucio wrote: > > > > On Saturday, 30 July 2016 02:52:25 UTC+2, Matt Harden wrote: >> >> I like submodules, but they do only work when you're using git and only >> vendoring projects that also use git. >> >> >>> >>> It seems to me that the solution is staring us in the face. I know > nothing about git submodules, but they have been raised in this forum > before and the only criticism has been that no other VCS has them. If they > accomplish what Go developers need, then Go must model any solution on them. > > It surely does not make sense to overlook them because no other VCS has > them: in favour of what? No other VCS has anything better or even as good. > So, within reasonable limits, (a) Go needs to adopt Git submodules and (b) > Go must provide analogous tooling for alternative VCSs. > > Inventing something totally orthogonal to serve the same purpose would be > unreasonable. > > I appreciate that Git submodules are not the final answer, but I do > presume that they ought to be the foundations for any discussion. > > Lucio. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
