Dependency Management session at GopherCon

[Andrew Gerrand]

Hi all,

Please accept my apologies for the late notice of this message.

On Wednesday at GopherCon there'll be a Go Project room for interested folk to work on stuff related to the Go project. I have earmarked some time on that day discussion package management.

My personal goal with the session is to better understand the problems, so that I can help guide the community toward some standard solutions.

Specifically, I'd like to try to get a big picture of the needs of the community. There are two major facets to the problem: the new user experience and the experienced user experience.

The outcome of the session should be a document that describes the major issues and the current or potential solutions.

I don't expect any decisions to be made during the session; that will happen through discussion online by way of the proposal process.

If you are not attending GopherCon, please feel free to mail me your thoughts on these topics (or point me in the direction of existing documents that you think should be considered). I will make sure these ideas are represented in the session, and in the resulting document.

Andrew

[Sam Boyer]

Can we please make sure to have a hangout set up for those of us who couldn't make it to Gophercon, but would like to be a part of this session? I'm perfectly fine with also emailing my thoughts, but that doesn't really take the place of being (at least virtually) present for the discussion.

[Brad Fitzpatrick]

I don't think the conference wifi will be sufficient for a Hangout. Nor do we have suitable displays & mics. Sorry. :-/

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Gerrand]

Brad's right. We tried to work with the organizers to organize hangout facilities, but we couldn't get it together in time.

In any case, I see this as just part of the conversation, not the end. Everyone should have ample opportunity to contribute to this process.

[Brad Fitzpatrick]

Can you elaborate?

On Tue, Jul 12, 2016 at 9:39 AM, Daniel Skinner <dan...@dasa.cc> wrote:

I'm actually at gophercon but not sure I need to be there just to say I think the point-of-no-return should be delayed a release cycle before 1.7 is cut.

[Daniel Skinner]

I'm actually at gophercon but not sure I need to be there just to say I think the point-of-no-return should be delayed a release cycle before 1.7 is cut.

On Tue, Jul 12, 2016, 8:29 AM Andrew Gerrand <a...@golang.org> wrote:

[Daniel Skinner]

I'm not suggesting it might be removed in the future, but rather it might become desirable to tweak the rules enforced. I assume the point of no return means it falls under the compatibility promise and it'd be a shame to lock in the experiment. So, what's the rush?

A weak point I see for example is the recommendation that apps use vendoring but libs shouldn't. When libs do, the longest-path-wins is straightforward but can really become a mess and feels very unlike other go tooling. For the sake of example, enforce vendoring availability for main packages only, such a change just wouldn't be possible after point of no return.

Given audience temperature of the main hall yesterday when vendoring was brought up, just seems easy to give more time to the experiment as developers have been using the feature and gathering more experience.

[samuel....@gmail.com]

(Just emailed you my thoughts, Andrew.)

C'est la vie. I appreciate y'all trying. Maybe I'll be able to find someone to get me in on audio-only over the conference wifi :)

Though...I should note. My sense is that, for those of us engaging deeply in this problem, we're a bit marooned. Well...really, I'll just speak for me. There's a lot of shamanic hand-waving about "how do we phrase these ideas in a way the Go team would find palatable?" or its flipside, "how do we get the Go team engaged enough in the complexity of these issues - that they typically don't experience firsthand - that we get real traction?"

I don't raise this to cast blame re: that state of affairs - only to highlight why any opportunity for "official" engagement feels like something to fervently jump on, assurances that decisions won't be made notwithstanding. Decisions may not be made, but discussion contexts will be set.

[Andrew Gerrand]

On 12 July 2016 at 12:15, Daniel Skinner <dan...@dasa.cc> wrote:

I'm not suggesting it might be removed in the future, but rather it might become desirable to tweak the rules enforced. I assume the point of no return means it falls under the compatibility promise and it'd be a shame to lock in the experiment. So, what's the rush?

When we turned it on in default in Go 1.6 we locked its behavior in, so really the point of no return for those particular semantics was the release of Go 1.6.

[Daniel Skinner]

Ok, thanks for the clarification.

[Chris Broadfoot]

Hi everyone, notes from the session are here:

https://docs.google.com/document/d/1xMJ0c-YxvcgNglzjbALzncs5_Acr0MST29oMf9TkgQI/edit

--

[Matt Farina]

Thanks for sharing the notes from the session.

It would have been nice if all the folks present with an interest in package management were invited. For example, Matt Butcher (the person who started Glide) was at GopherCon and looking for a session to discuss this very topic. Yet, this was in a room with no sign and he was in the next room over but he didn't hear a word about it until the discussion was done.

If people have intelligent well through out opinions based on experience and want to be involved it's worth looping them in.

In any case, my stance is that I want the problem solved well. We can learn a lot from other languages as they are all solving this problem and most are doing it in a very similar way. I'm happy to help and open to discussion and code to solve it.

Disclosure, I work on Glide. I'd rather see the problem solved well than see Glide live on or have to develop it.

[Peter Bourgon]

In fairness, the session was advertised heavily on Gophers Slack
#vendor (which is the defacto home for these discussions) for days or
weeks beforehand, and posted to this mailing list (albeit somewhat
late). Also, none of the involved parties, to the best of my
knowledge, knew that Matt was even there... too bad. But I think the
core group of folks are forming now, and I'm sure future discussions
will happen in #vendor. Please ask him to drop in.

> "Go Package Management" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to go-package-manag...@googlegroups.com.
> To post to this group, send email to go-package...@googlegroups.com.

[Matt Farina]

Peter and anyone else,

If I may, I'd like to make a few suggestions.

1. This effort should learn from history. Package management is not new. Platforms and languages have been doing it for decades and have learned a lot. We don't want to repeat historical mistakes and want to learn from their wins.
2. Make #vendor in slack a welcoming place. I've felt unwelcome enough by some of the members that I'm rarely around. I know others, with well thought out stances who would put in effort to solving this, feel the same way. That's why I didn't know about the meeting to tell Matt. I will try to make a better effort to poke at the room.
3. Make sure people who can solve this well are invited in if they are not already there. Enough people who are off doing this well are focusing on other things at the moment rather than sitting around talking about vendoring. 

I'll make a better effort to be looped in. But, just counting on people following a room in slack and keeping up in the backchannel isn't a good communications method.

- Matt

> email to go-package-management+unsub...@googlegroups.com.

[Peter Bourgon]

#vendor isn't the backchannel. It is the primary channel. I'm sorry
you felt unwelcome; I don't have authority there but I will make an
effort to be as welcoming as possible.

On all other points we are completely agreed. Everyone, including I
think the Go team, wants to learn from the folks who have already been
in this space for a year+.

>> > email to go-package-manag...@googlegroups.com.

>> > To post to this group, send email to go-package...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Go Package Management" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to go-package-manag...@googlegroups.com.

[Andrew Gerrand]

On 15 July 2016 at 07:42, Matt Farina <matt....@gmail.com> wrote:

It would have been nice if all the folks present with an interest in package management were invited.

I mailed golang-dev and go-package-management as soon as I had organized the session. I also tweeted about it. I just didn't know Matt was around! If I had, I would have definitely invited him over.

I second Peter's suggestion we use #vendor as the primary channel for discussing this. I'm there.

[Edward Muller]

+1 on #vendor as primary, with the proposal process (and emails to go-pm / golang-dev) as a way to circulate / get further feedback.

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.
To post to this group, send email to go-package...@googlegroups.com.

[Matt Farina]

-1 for #vendor all the time

Some of us are working on a number of hard problems which means we don't have much time to scroll through sometimes many messages and show up to ad-hoc meetings.

It's also going to be hard with people distributed across timezones. Pacific timezone isn't convenient with EU timezones or some of us in the ET.

Ad-hoc conversations in #vendor will privilege those always present far more than those with wisdom or invested in coding the solution.

#vendor is a good place to have conversations when they happen. It just can't be the only communications channel.

On Friday, July 15, 2016 at 12:54:21 PM UTC-4, Edward Muller wrote:

+1 on #vendor as primary, with the proposal process (and emails to go-pm / golang-dev) as a way to circulate / get further feedback.

On Jul 15, 2016, at 9:12 AM, Andrew Gerrand <a...@golang.org> wrote:

On 15 July 2016 at 07:42, Matt Farina <matt....@gmail.com> wrote:

It would have been nice if all the folks present with an interest in package management were invited.

I mailed golang-dev and go-package-management as soon as I had organized the session. I also tweeted about it. I just didn't know Matt was around! If I had, I would have definitely invited him over.

I second Peter's suggestion we use #vendor as the primary channel for discussing this. I'm there.

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-management+unsub...@googlegroups.com.

[Andrew Gerrand]

I agree that real time conversation favors people who are present. I personally have a hard time with real time conversations because of my general workload. I try to shut myself off from the world for many hours at a time to get things done.

Ideas:

- someone could volunteer to write a weekly summary of significant conversations in #vendor and post it to go-package-management,

- alternatively, establish a convention that whenever a significant conversation happens in #vendor, one of the participants posts a summary to go-package-management@ to keep others up to speed, and to continue the conversation there.

- ?

In any case, we're going to have to make an effort to be inclusive and document what we're talking about. This might also help focus our discussions, if we know we're going to be writing them up afterward. But maybe these suggestions are just flat-out onerous? What do people think?

As for me: I am impressed by the document that is in the #vendor topic, and also by the stuff that was sent to me in the lead up to the dependency meeting. I'm still thinking about how to best focus on the way forward. When I get back to Australia in a week or so, I hope to have written up more of my thoughts. (In particular, I'd like to formulate a set of use cases or "user journeys" that will help guide us. (let me know if something like this already exists.))

Andrew

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.

To post to this group, send email to go-package...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.

[Jessica Frazelle]

So we had very much this same exact argument with docker networking when we were first designing it. And like all problems there are trade offs. There is no way to make everyone happy.

I believe we ended up doing a mix of IRC and a mailing list but it ended up fragmented and of course people weren't happy. I would say if you care enough about go vendoring you should try to use the channel where the most people are interacting. It's a lot easier for 1 individual to change their routine to interact with a group then to change the whole group, especially if you care enough about the feature. 

Maybe then we can use the time we would have used complaining about the means of communication to communicate about the feature itself.

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.

To post to this group, send email to go-package...@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-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu

[Chris Broadfoot]

Decisions shouldn't be made via real-time communication (i.e., #vendor). I suggest that discussion of decisions should be made via something less ephemeral.

At Google, design discussions are performed via a design doc (usually in Google docs)*. I think the doc produced by #vendor is a good place to have discussions.

Anything that comes out of #vendor should make it into that doc, which can then be commented on by those who can't be present in #vendor.

Does that sound reasonable?

* and also in person (which is kinda like #vendor), but the source of truth is the doc.

[mbut...@deis.com]

Yes, I was disappointed to have missed the session. I was about 50 feet away during the meeting. Thanks for sharing the notes, though.

The Glide team as a whole (especially Matt Farina and Sam Boyer) has done a vast amount of research on dependency and package management. And we are far more interested in getting the problem solved, not in promoting a product. But we have felt intentionally pushed out of several salient discussions (and #vendor has not been a welcoming place for us, or for Glide's users).

That said, we're always interested in participating in efforts to solve this problem for the Go development community at large. So if there is potential to be involved in solving a problem (and not just debating why one package manager is better than another), we'd enthusiastically participate.

Thanks again for sharing the notes. I really appreciate that.

[Edward Muller]

I’m sorry that #vendor hasn’t been an inviting place for you or glide users. When I started the doc it was an effort by myself to help drive consensus and discussion (PS: Just because we disagree doesn’t mean we can’t discuss, in fact I’d argue it means that we should discuss MORE and MORE often). I haven’t done much in #vendor or with the doc in the last few month or so though, so most of the good work can be attributed to others.

When I +1’d using #vendor earlier I didn’t think about the geographical distribution of people and (TBH to my detriment) have become somewhat numb to actually being ‘offline’ (I’m supposed to be off right now myself). I’m sorry.

I can’t wait for Andrew to feel he is up to speed.

Looking forward to discussing this more with people though whatever medium is decided.

>
> That said, we're always interested in participating in efforts to solve this problem for the Go development community at large. So if there is potential to be involved in solving a problem (and not just debating why one package manager is better than another), we'd enthusiastically participate.
>
> Thanks again for sharing the notes. I really appreciate that.
>

[Matt Farina]

Andrew,

I'll start to go through the doc in the #vendor topic and provide feedback but I find it has some major gaps. Some additional things to look at for more background and context:

• An alternative manifest and lock spec. What I think makes it interesting is the link to use cases it helps you solve.
• A quick overview of how package managers in other languages handle this problem.
• My quick (not deep) view on solving the go package mgmt problem.

Some of us have put a lot of thought into this space before the #vendor doc existed.

- Matt

On Friday, July 15, 2016 at 2:21:41 PM UTC-4, Andrew Gerrand wrote:

I agree that real time conversation favors people who are present. I personally have a hard time with real time conversations because of my general workload. I try to shut myself off from the world for many hours at a time to get things done.

Ideas:

- someone could volunteer to write a weekly summary of significant conversations in #vendor and post it to go-package-management,

- alternatively, establish a convention that whenever a significant conversation happens in #vendor, one of the participants posts a summary to go-package-management@ to keep others up to speed, and to continue the conversation there.

- ?

In any case, we're going to have to make an effort to be inclusive and document what we're talking about. This might also help focus our discussions, if we know we're going to be writing them up afterward. But maybe these suggestions are just flat-out onerous? What do people think?

As for me: I am impressed by the document that is in the #vendor topic, and also by the stuff that was sent to me in the lead up to the dependency meeting. I'm still thinking about how to best focus on the way forward. When I get back to Australia in a week or so, I hope to have written up more of my thoughts. (In particular, I'd like to formulate a set of use cases or "user journeys" that will help guide us. (let me know if something like this already exists.))

Andrew

On 15 July 2016 at 11:33, Matt Farina <matt....@gmail.com> wrote:

-1 for #vendor all the time

Some of us are working on a number of hard problems which means we don't have much time to scroll through sometimes many messages and show up to ad-hoc meetings.

It's also going to be hard with people distributed across timezones. Pacific timezone isn't convenient with EU timezones or some of us in the ET.

Ad-hoc conversations in #vendor will privilege those always present far more than those with wisdom or invested in coding the solution.

#vendor is a good place to have conversations when they happen. It just can't be the only communications channel.

On Friday, July 15, 2016 at 12:54:21 PM UTC-4, Edward Muller wrote:

+1 on #vendor as primary, with the proposal process (and emails to go-pm / golang-dev) as a way to circulate / get further feedback.

On Jul 15, 2016, at 9:12 AM, Andrew Gerrand <a...@golang.org> wrote:

On 15 July 2016 at 07:42, Matt Farina <matt....@gmail.com> wrote:

It would have been nice if all the folks present with an interest in package management were invited.

I mailed golang-dev and go-package-management as soon as I had organized the session. I also tweeted about it. I just didn't know Matt was around! If I had, I would have definitely invited him over.

I second Peter's suggestion we use #vendor as the primary channel for discussing this. I'm there.

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-management+unsub...@googlegroups.com.

To post to this group, send email to go-package...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-management+unsub...@googlegroups.com.

[Matt Farina]

Andrew,

I'd like to ask that Jason Buberel or someone he thinks has good insight is involved in the discussions. He knows a fair amount about what the ecosystem is looking for in package management tooling.

Thanks,

Matt

On Friday, July 15, 2016 at 2:21:41 PM UTC-4, Andrew Gerrand wrote:

I agree that real time conversation favors people who are present. I personally have a hard time with real time conversations because of my general workload. I try to shut myself off from the world for many hours at a time to get things done.

Ideas:

- someone could volunteer to write a weekly summary of significant conversations in #vendor and post it to go-package-management,

- alternatively, establish a convention that whenever a significant conversation happens in #vendor, one of the participants posts a summary to go-package-management@ to keep others up to speed, and to continue the conversation there.

- ?

In any case, we're going to have to make an effort to be inclusive and document what we're talking about. This might also help focus our discussions, if we know we're going to be writing them up afterward. But maybe these suggestions are just flat-out onerous? What do people think?

As for me: I am impressed by the document that is in the #vendor topic, and also by the stuff that was sent to me in the lead up to the dependency meeting. I'm still thinking about how to best focus on the way forward. When I get back to Australia in a week or so, I hope to have written up more of my thoughts. (In particular, I'd like to formulate a set of use cases or "user journeys" that will help guide us. (let me know if something like this already exists.))

Andrew

On 15 July 2016 at 11:33, Matt Farina <matt....@gmail.com> wrote:

-1 for #vendor all the time

Some of us are working on a number of hard problems which means we don't have much time to scroll through sometimes many messages and show up to ad-hoc meetings.

It's also going to be hard with people distributed across timezones. Pacific timezone isn't convenient with EU timezones or some of us in the ET.

Ad-hoc conversations in #vendor will privilege those always present far more than those with wisdom or invested in coding the solution.

#vendor is a good place to have conversations when they happen. It just can't be the only communications channel.

On Friday, July 15, 2016 at 12:54:21 PM UTC-4, Edward Muller wrote:

+1 on #vendor as primary, with the proposal process (and emails to go-pm / golang-dev) as a way to circulate / get further feedback.

On Jul 15, 2016, at 9:12 AM, Andrew Gerrand <a...@golang.org> wrote:

On 15 July 2016 at 07:42, Matt Farina <matt....@gmail.com> wrote:

It would have been nice if all the folks present with an interest in package management were invited.

I mailed golang-dev and go-package-management as soon as I had organized the session. I also tweeted about it. I just didn't know Matt was around! If I had, I would have definitely invited him over.

I second Peter's suggestion we use #vendor as the primary channel for discussing this. I'm there.

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-management+unsub...@googlegroups.com.

To post to this group, send email to go-package...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-management+unsub...@googlegroups.com.

[Andrew Gerrand]

Thanks for the links.

Of course, I'm aware there's been ongoing work in this space for many years. I'm just trying to make sure I am across everything that's going on before jumping in with my own thoughts.

On 15 July 2016 at 13:59, Matt Farina <matt....@gmail.com> wrote:

I'd like to ask that Jason Buberel or someone he thinks has good insight is involved in the discussions. He knows a fair amount about what the ecosystem is looking for in package management tooling.

I've been talking to Jason about this, and he has essentially handed this off to me. So I suppose I'm that someone. I hope those that have worked with me would say I have "good insight" but I'm not sure exactly what that means.

Andrew

[Dave Cheney]

Sounds good to me.

You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[Ralf Schülke]

Hi,
i think vendor are not the best idea for golang, well outside of the STL are many packages experimental (not finish, bugy, side effects on goos/goarch and secure problems and not maintained).
The best way is we have rules for new STL packages and official maintained, all other package need explicit installed, this means download the packages and put in your project (src/myapp/pkg-vendor). For good packages need golang EXTRA-Lib. In the future we need, drawing stuff and rendering stuff eg. vulkan, sound etc. But he can,t not run on all GOOS,GOARCH thats a problem, eg. Plan9 have no OpenGL driver, so its make no sense to have this in the STL, but in the EXTRA-Lib he are maintained by golang project.

So best solution are, live in the STL,  in golang, and outside of the own risk.

go get-vendor vs go go get:

go get - work with your GOPATH  // shared, global
go get-vendor - work explicit in your project  // static, private

thanks

[ck...@signal.co]

+1 for learning as much as possible from the past experience of any and all programming languages that have implemented dependency management. If the conclusions of any one are not relevant, then let that be discovered thoroughly. All other learning could do nothing but advance the sophistication of Go's decisions on the subject. Focus on the Google Document for Comparison of Programming Language Package Managers

[Ralf Schülke]

I do not think that a golang LPM needs, it only requires a clear regulation on the "Vendor" packages, so go libs and other extensions. For one has golang his STL, these belong to the language and are well documented and tested and run on all systems. "Vendor" packages other hand there are not, and may under some circumstances a risk. The question is how are these "Vendor" packages are displayed in GOPATH, as many put their GOPATH only once and not oriented project. Actually, everything can remain so only should golang project good packages promote alongside the STL example as Oficial "Vendor" lib, here then could clean things, such as eg GL, volcano or UI, here you should only distinguish between all platforms or only for a specific, for example Linux, x86_64, arm64 / all x86_64 / Window 64 only etc.

The beneficial as an official vendor packages are:
- Stable api
- Well documented
- Better at shooting training in the selection (the package useful for my projects, it runs on my target system, etc)
- The quality same as golang STL

[Peter Bourgon]

Hello,

For well over a year, a group of dedicated Gophers have been
discussing the package management situation on a dedicated mailing
list, in Slack #vendor, and several communication channels. A few
tools have emerged from those broad conversations, including Glide,
govendor, gb, and the SAT solver gps. And at GopherCon 2016, a panel
with several members of the core Go team was held.

While much remains to be decided, a few things are clear. The package
management solution, whatever it will be, will take the form of one or
more official Go language proposals. And the proposals (and their
eventual implementation) will be driven by a small committee of
dedicated Gophers.

In the interest of progress, I've volunteered to shepherd this process
from start to finish. I've created a document detailing a proposal for
the process itself. If this topic interests you, please review and
comment.

https://docs.google.com/document/d/18tNd8r5DV0yluCR7tPvkMTsWD_lYcRO7NhpNSDymRr8

As much as anything can be official, I hope that this will be the
official process, leading to the long-desired blessed solution.

Regards,
Peter Bourgon.

[Jessica Frazelle]

I would be interested in being on the committee but I understand if now my position at Google prevents that. However I do have quite a bit of experience dealing with Go vendoring outside of Google. And was very opinionated in design of Docker, which despite some hate I think we can all agree it's ease of use is something to be desired out of Go vendoring. Right now things are difficult. I would love to make this simple and as intuitive as possible. I also think this is a super cool opportunity for Go as a language to make the most innovative vendoring experience there is. How fun would it be to go from being a "vendoring joke" if you will, to the coolest solution there is? ;)

Obviously I'm pretty late to the game but I care deeply about Go and making this right.

You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Peter Bourgon]

Sure! I don't think a Google affiliation is a disqualifier. Please add
your name to the list of interested parties :) Same goes for anyone.

[Matt Farina]

Jessica, glad to see you're interested. It's great to see folks want to be involved who have experience dealing with the more complicated vendor trees. You can help us keep in mind the cases where it's not just 4 or 5 dependencies that are easy to mentally track.

> email to go-package-management+unsub...@googlegroups.com.
> To post to this group, send email to go-package-management@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-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Aaron Schlesinger]

Hello all,

I'm also late to the game here, and I hope it's not too late to add my name to the doc (which is view-only right now, so I can't add it). I think I have a lot to offer, both in terms of solutions and the pains of today's Go dependency management. I work with the k8s.io dependency tree daily at Deis - one of the biggest trees I know of - and I've started building https://github.com/arschles/goprox to (at least) stabilize our external dependencies. I'd love to see goprox not have to exist anymore. I care a lot about this community and I can't tell you how cool it would be to see us get package management right.

> email to go-package-management+unsub...@googlegroups.com.

[Zellyn]

On the contrary… I have been dreaming of kidnapping Googlers on the Go Team and forcing them to work at my company for a month or two so they can experience packaging/vendoring outside of /google3/  :-)