On Tue, Mar 7, 2017 at 6:47 AM, Sam Boyer <samuel.d.bo...@gmail.com> wrote:
> Hi folks, > > Since we opened up the dep project <https://github.com/golang/dep> in > late January, there's been flurry of contributions, which has been great. > However, the plans and end goal of dep haven't been entirely clear to > everyone. > > To address that, and help guide contributors, we've put out a roadmap > <https://github.com/golang/dep/wiki/Roadmap>. > > We're hoping to have dep ready to merge into the toolchain at the > beginning of the 1.10 cycle. But that'll only happen if the community steps > up even more to help! > Hi Sam, You make it sound like dep is just going to become 'go dep' in Go 1.10. That's not the plan I thought we discussed. As I wrote to you and the package management group in January: I think it's very important instead to weave package and dependency management into the go command so that you don't notice it as a separate thing in day-to-day work. As a result, I see dep as an important improvement over current practice that's usable immediately, an important step toward a final solution, and also an experiment that helps us learn more about what structure works for people, but I don't see it, for example, as a prototype of the eventual go command integration (since it's not integrated at all). In particular, I agree strongly with all of these decisions in dep: - Manifest file listing version requirements. - Lock file listing exact versions for a reproducible build. - Version control repo as project granularity is good. - Calling the group of packages released as a unit a "project" is a good name to establish. - Implementing coordination with the build by populating vendor is clearly the right implementation. For eventual integration with the go command and the broader go toolchain, some of the decisions are likely not optimal. In particular: - go get vs not. Dep creates a parallel world separate from 'go get'. Having two is not great. Ideally, I'd like 'go get' to improve instead of adding a second mechanism. - Subcommand complexity. As mentioned in #25, if dep foo became 'go dep foo', then it would be the first sub-sub-commands and likely indicates a less than clean integration. - Vendor directories. As an implementation mechanism today, these make sense. They stop making sense if we can change the toolchain. Instead of translating the lock file into an ephemeral vendor directory, the tooling can just read the lock file directly. - Multiple packages. At scale, I think allowing v1 and v2 of a single package to be linked into the final binary is unavoidable. It's also not possible to express in the "top-level vendor directory" model. Another reason to eliminate the "translate lock file to vendor directory" step. - GOPATH vs not. As I understand it, dep continues to assume GOPATH, but in a multiversion world that may not be appropriate. We need to understand the implications here. GOPATH has to keep working well, but I think we probably want 'git clone foo && cd foo && do work' outside GOPATH to work equally well, and package management has an important role to work out here. I understand that not changing the go command was a constraint from the discussions at Gophercon and also from the point of view of making something people can use today. That's absolutely appropriate and correct for dep. But for long-term integration, I think we do need to rethink these aspects of the go command itself. By far the most important things to do with dep right now are (1) build something people can use and get benefit from today and eliminate blockers to adoption and (2) based on experience with that usage, learn what the eventual design and go command integration should look like. It's important to note that I do not expect projects using dep to automatically work with the new go command integration too. In particular, I expect that the lock and manifest files will change in syntax and therefore file name during integration into the go command, so that it is possible for projects to work with both dep and the go command during a transition. I also expect that we need to have a discussion about supported version constraints, to avoid forcing our tools to solve NP-complete problems <https://research.swtch.com/version-sat> (it's not just crazy hard, it's crazy hard to explain to users when it breaks). The best input to that discussion will be examination of what dep users use. I also was hoping to have more thoughts fleshed out more than a month ago, but I've had a sequence of higher-priority interrupts and haven't had a chance to do that yet. That's on me, and I apologize for that. (I'm not going to be around a lot for the next three weeks either, so likely not much will happen on my end until April.) Dep is another important step - just as vendor dirs were - in the effort toward proper package management within the go command. It's a way for us to learn more about what works and what doesn't. There will be iteration and revision and almost certainly rethinking on the way into the go command proper. My concern is that the roadmap and some recent Reddit comments <https://www.reddit.com/r/golang/comments/5y06i3/dep_roadmap_to_becoming_the_official_dep_mgmt_tool/deo0qcp/?st=j08llk2p&sh=08200fe4> do not reflect that level of uncertainty. I believe we're still very much in the "build and experiment and learn" phase, not the "polish and ship" phase. Russ -- 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.
