Random rant: I have this coworker who's unable to articulate an opinion or argument without being a righteous douche. As an example, here he is in a public and widely used Slack channel, learning about how Go imports work (they're URL-based and the go tool downloads them to your hard drive, kinda like npm except you point to github URLs or whatever instead of a package name that a web package manager knows about):
Quote:
Him: I am being prompted to enter my RSA key for access to a private git repository. Is this expected?Getting Go dependencies
github.com/<username>/<repository we use> (download)
Enter passphrase for key ‘/Users/<hisname>/.ssh/id_rsa’:
That’s not going to work for random developers
Me: try `ssh-add -K ~/.ssh/id_rsa` ?
Him: That is not the point.
Me: it's not a private repository
Him: It’s not owned by <our company>.
A few other devs: chiming in with random tips on SSH stuff
Him: Why does company software depend on a developer’s private github?
Me: welcome to the wonderful world of go
Him: Nope.
Me: ok
Anyway, submitted a large PR today and asked him to take a look at part of it
Quote:
Him: This makes every Go target depend on a global list of <source files with weird dependency issues>? That doesn't seem right.
If you really want this dependency, the list of sources should be passed in to the macro, so the dependency is not hidden.
It would probably be better to do something like
target_link_libraries(target PUBLIC weird_dependency_issue_thing)
so a Go target will be automatically rebuilt when the source changes.
Pretty reasonable request, but there's a reason I did it this way so I set out to explain all sides of it
Quote:
Me: There are tools you can run to get a list of sources that a given Go target depends on, but they're kinda slow, so the build wound up being a lot faster if I just said "ok, every Go target depends on every Go file". That's basically the behavior this line is propagating.
Explicitly passing in the dependency vs hiding it implicitly each have a cost:
- explicit passing: if you forget to include the dependency, you might get unexpected behavior because a changed source file fails to trigger a rebuild
- implicit hiding: targets that don't use this type of source will rebuild when one of those source files changes
I prefer the cost of the 2nd one (which is annoying) over the 1st one (which can actually hurt you), though obviously a solution that mitigated both of those issues would be preferred if I could figure one out.
...aaaaaand any challenge to his opinion is NOT WELCOME
Quote:
Him: If you want to add bogus dependencies, you can do that in CMakeLists.txt for each target.
Don't force this behavior on other developers by embedding it into a utility macro.
Regarding the last comment, worth noting that the number of "other developers" I am "forcing" this behavior on is zero, because I am the only person writing code in Go on this project.
Another coworker gchatted me after that like "yeah man stop adding bogus dependencies to our targets" (obv being sarcastic). The guy's smart but basically immovable on any opinion he holds and incapable of giving ground or conceding merit to people who disagree with him, really a pain in the ass to work with