paulsamways

13 ปีที่แล้วdiscuss

See http://research.google.com/pubs/pub38125.html

13 ปีที่แล้วdiscuss

So the key part of the update I was referring to was the following:

  Because of course that's not how it really works. Instead, it makes 
  a local copy of that external library. And if you have a local copy, 
  you can edit it. And meanwhile, that person you copied the OpenGL code 
  from? They are also changing their version (fixing bugs, adding features, 
  adding bugs).

In short, original developer has the clone of the OpenGL library in their 'src' directory. While working on Haunts his making changes to it and not pulling updates from upstream. All is well, things will always build on his machine because as you say, it won't update unless he does 'go get -u'.

Fast forward to when the community takes over, they clone the Haunts project and attempt to build it. Now they are using the HEAD of the 'github.com/go-gl/opengl/gl' repository, as specified by the imports path and they find that it no longer compiles.

This is where the problem exists.

The simplest way around this problem is to simply fork the OpenGL Go library (like they have), and reference the fork in the import path. That way no matter what happens in the upstream repository, the Haunts project will continue to compile. The original developer could of then just pushed the changes he was making in his local 'src' directory back to the fork and everything would be fine. When they are ready to take updates from upstream, they simply update their fork and then 'go get -u' on all developer machines.

By forking, or maintaining your own copy of library, you get a level of isolation from the upstream developers.

What you are saying is 100% correct, the Go tools automatically give you this when running 'go get', it clones the library into your 'src' directory. What I am saying is that when working in a team/community environment, you need an additional level of isolation (the fork), so that the entire team can be using the exact same version of the library.

  > I feel like one of us is bat shit insane, and at this point, I am just hoping it isn't me.

I don't think (hope) either of us are, just not thinking on the same track :) I hope what I've written is clear enough that you can see what I was saying.

paulsamways

13 ปีที่แล้วdiscuss

I know how it works :) I'm not new to Go.

BUT, what you are describing is exactly how the Haunt guys used Go and consequently the issues they have run into. Please re-read the update from Rick and read my comments again, you should then understand the issue and why changing the import path to a fork/clone/localized copy is beneficial (though not required).

paulsamways

13 ปีที่แล้วdiscuss

> No need to fork, it puts a copy of those libraries under ./src, so you always have a sealed (hermetic) referentially complete copy.

While that is true, it doesn't solve the problem with distributed teams. The library path MUST be pointing to a 'localized' repository to solve the problem the Haunt guys are having.

paulsamways

13 ปีที่แล้วdiscuss

> and put import ("github.com/go-gl/opengl/gl") directly into your code. Viola! Thus hilarity ensues.

Of course it does! All they had to do is fork the project (which they have) and reference that it instead. Viola, problem solved!

paulsamways

13 ปีที่แล้วdiscuss

Won't disagree with you there! Though sometimes going outside your comfort zone can be a good thing.

paulsamways

13 ปีที่แล้วdiscuss

More people should be doing this. You don't even have to move out of tech yourself, find a position in a company where tech is only ancillary, not the core focus. You'd be surprised just how many real problems are out there waiting to be solved.

paulsamways

Submissions

A case of mistaken encoding

comments