Really? Does it flatten dependencies or will I still have potentially more than one context package for example?
On Sun, Jul 17, 2016, 00:11 William Madison <wmadison...@gmail.com> wrote: > FWIW, go build in versions >= 1.6* is basically equivalent to what GB buys > us just with a different structure for the vendor directory (i.e /vendor vs > /vendor/src in GB). The gb-vendor plugin is a jewel in its simplicity and > makes fetching/managing vendored packages very easy, which is what I love > about GB as a build tool specifically when the end product is a binary. If > I were authoring a library I'd definitely stick to the go tool chain given > that GB projects aren't go gettable. > > - Will > > On Sat, Jul 16, 2016 at 5:44 PM, Henrik Johansson <dahankz...@gmail.com> > wrote: > >> Well they have issues too of course. The most recent left-pad debacle is >> most striking. >> >> In general they do have support for versions all of them. Not all are >> SemVer, the older seems more fluid on the interpretation of what is a valid >> version but they have it. There are often many or at least a couple of >> different tools for each language for example Maven, Gradle, SBT, Ivy etc >> in the Java landscape. Ruby has a number of such tools as does python. In >> the static compiled family the two outstanding examples are Haskell and >> Rust. >> Cabal has had it's problems but the community seems happy with it. The >> Rust people are all on board with Cargo it seems and it is afaik the >> solution that would work best for Go to look at. It is in essence a >> declarative file with dependencies (and some extra stuff) which would be >> super easy for Go to adopt. Even having the go tool do it seems very >> easy. The different tools behave differently in how they work to resolve >> compatible versions. Some have a range notation, some have default >> selection and some bail. Bailing or allowing the user to choose seems the >> best possibly with a range notation. >> >> This you are no doubt aware of already, I just wanted to list where I >> come from when I say that it is considered solved. >> Not that all possible kinks are hammered out but that it seems to work in >> a way that a large number of people are OK with. >> >> Personally I really like the vendor concept but the thing where one of my >> deps can have the same type as a dep as I do but from my perspective the >> types of these two are different when they really are the same seems very >> fishy. >> Flattening makes it better but then something can break because the wrong >> "version" was chosen. >> Having a common versioning scheme would make this much easier and safer >> even if we occasionally would run into the diamond problem. At least we >> would know that there was an issue and can take steps to fix or work around >> it. >> >> Having versions would also not hinder tools to resolve and fetch all deps >> every time if they want to nor does it stop vendoring. In my mind what we >> have today is hidden versions without any easy way to see or choose what we >> want. >> Having the go tool be version aware may be a too invasive change but it >> would not be hard. >> >> I don't know, I feel as though I am missing something. It feels so >> obvious to me that when you guys don't see it the same I start wondering >> what I missed. >> >> Hope it makes some sense. >> > >> >> >> On Sat, Jul 16, 2016, 19:13 Ian Lance Taylor <i...@golang.org> wrote: >> >>> On Sat, Jul 16, 2016 at 5:29 AM, Henrik Johansson <dahankz...@gmail.com> >>> wrote: >>> > For repeatable builds there are many ways and tools that work fine, Gb >>> is >>> > not unique in this respect. >>> > >>> > I don't get why this should be a controversial topic however. It seems >>> to be >>> > an issue only in the go community. >>> > In all the other languages (newer more modern anyway) it is considered >>> a >>> > solved problem. >>> > Sure different tools pop up now and then but they all work in the same >>> > general way. >>> > >>> > I am sure there is a reason but why can't we just settle on the same >>> idea >>> > that everyone else is doing? >>> > Applications and libraries would all then use the same principal way of >>> > resolving dependencies and different tools could handle conflicts in >>> > whatever way the author likes. Vendoring or not it would work >>> regardless. >>> >>> My understanding is that what other languages do also has problems. >>> If there is a clear solution here, I certainly think we should adopt >>> it. >>> >>> Can you explain what it is that other languages do, and how we should >>> change to do the same thing? >>> >>> Ian >>> >> -- >> > 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. >> > -- 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.
