Don't couple your Go code to GitHub

Don't couple your Go code to GitHub(iain.rocks)

26 points by birdculture 3 hours ago | 10 comments

thih9 21 minutes ago |

> In my opinion, every commerical software development team using Go should be using custom domains for namespacing their internal libraries and packages.

I’d remove “go” from the above, i.e. I think same applies to other stacks.

Even using GitHub domain links in code comments gets problematic long term. Ie when a migration happens and those links start pointing nowhere.

handoflixue 8 minutes ago | |

I'm confused by the article, and this comment, treating these URLs as difficult to replace.

Why can't you just search-and-replace? Presumably all of them refer to "GitHub.com" and not much else code will, so I'd think this was an exceptionally easy case.

Even easier for comments, since them being obsolete for a few hours during a migration doesn't exactly break anything.

gravypod 7 minutes ago | | |

It's harder to replace in history.

gumby 18 minutes ago |

Seems like an error to use a URL. This is perfect for a URN or some other form of URI.

It could be a URN that used the DNS as a back end (though that’s a lot like a URL) so better would be something more abstract with multiple possible resolvers and a signature.

SenHeng 2 hours ago |

GitHub is almost forever. Your custom domain disappears when you stop paying the bills, which if you’re an open source developer has a higher likelihood than GitHub disappearing.

One day, we’re all going back to vendoring dependencies.

otterley 1 hour ago | |

Why did we stop vendoring dependencies in the first place?

collabs 14 minutes ago | | |

Because it sucks. But maybe it should suck? It would make us think twice before adding dependencies.

I use dotnet and I never liked seeing dlls and binary files in my diffs. I would argue if we are adding vendor code to our projects, we should demand the FULL source code instead of dlls. Maybe it is already possible with things like x unit. I have never given it much thought... But then that vendoree code has to come from somewhere as well, right? I mean there is something to be said about provenance or something here?

Sorry if this feels like a stream of consciousness because it is ↔

metaltyphoon 17 minutes ago | | |

Because its not as convenient

prasadvara 3 hours ago |

Isn't this going to introduce the dependency of domain management? I understand the positive side of it, but put some infra level manamgment layer to individual Open Source devs, just a thought. But yeah, positives vs negatives weigh and pick.

andreashaerter 1 hour ago |

There are also a few Hugo templates for vanity import paths.

Here's mine: https://github.com/foundata/hugo-theme-govanity (e.g. used at https://golang.foundata.com/ )

And yes I'm aware of the irony of hosting this on GitHub... still figuring out a good workflow for maintaining our OSS on Codeberg and GitHub in parallel fed from the internal forge. The dependency on our own domain is real but we favor it.