My reasoning was flawed. (also, I generally mean "one" when I use "we" :)
I think you're right with the project based approach in gb (for people interested in reproducible builds). I think that the pkg path issue (that leads to type equality issue) may be simply solved by having the vendor directory at the root of the project directory. (so no vendor directory per library) Any conflict caused by the evolution of a vendored package API would be stemming from the API surface having been augmented. That should trigger an update of the vendored library. (If the author did not keep with the backward compatibility requirement, then that would be a breach of versioning as Go defines it.) Maybe I am overlooking something still. On Friday, July 29, 2016 at 1:46:26 AM UTC+2, Dave Cheney wrote: > > Who is we ? You and me ? > > On Friday, 29 July 2016 08:50:47 UTC+10, Chad wrote: >> >> So if we decided that vendoring always used HEAD, that would ideally >> force people to have stable APIs (plus, why vendor an unstable/ in-flight >> API anyway) >> >> Couldn't it enable a change of behaviour for go get when a vendor >> directory is detected and solve some of the issues related to type equality >> (by having a single pkg path for a vendored package) ? >> >> >> >> On Friday, July 29, 2016 at 12:14:02 AM UTC+2, Dave Cheney wrote: >>> >>> Yes, exactly. >> >> -- 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.
