5 ms·

Most of the time this will be a Github or Gitlab URL. (Or similar.) Then domain name expiration isn’t a problem, but you do need to protect your account. Using

Most of the time this will be a Github or Gitlab URL. (Or similar.) Then domain name expiration isn’t a problem, but you do need to protect your account. Using a personal domain name should probably be discouraged unless you’re sure you know what you’re doing, and even organizations might want to think hard about whether they’re really want to maintain a website indefinitely.

janosdebugs 3y ago
One could argue that if the personal website goes away, you should be taking a hard look at that dependency anyway as it may have become unmaintained. Also, you can use vendoring if this is a concern.
ncjcuccy6 3y ago
Did the article somehow suggest GitHub.com might expire?
- janosdebugs 3y ago
  No, the article suggested that when hosting a Go package on your private domain that domain might expire. However, most Go packages are published as the module name being github.com/author/packagename, in which case domain expiry is not a problem, but you need to keep a hold of the account.
- skywhopper 3y ago
  The risk with GitHub is more likely that the source account of the library would be removed for any of a hundred reasons.
mort96 3y ago
I was once unable to build some Go software because some random individual's personal git hosting website was down. It's sadly not only gitlab or gitlab; at least that would've limited the amount of single points of failure.
- assbuttbuttass 3y ago
  Downloads will typically be cached by a module proxy, which can protect against downtime on the hosting site https://go.dev/ref/mod#goproxy-protocol https://go.dev/ref/mod#goproxy-protocol
mrweasel 3y ago
> Then domain name expiration isn’t a problem Unless Github or Gitlab goes out of business. Github might not be much of an issue, but what is some shifty company buys Gitlab during the next financial crisis? Github has Microsoft money, so I wouldn't be to concerned, but even yanking Gitlab could break an insane amount of modules in one go. Having modules distributed among many domains reduce the chances of a large scale issue, for the cost of many small problems.
- weego 3y ago
  If github just falls out of existence as a business with no warning I think go module issues will be just one of an impossibly long list of issues we'll all have
- hnlmorg 3y ago
  As much as GitHub might try to convince people otherwise, Git is a decentralised version control system. Which means if a cloud git service goes offline tomorrow, anyone who already cloned that repo still has a verbatim copy of the code that can seed a new upstream source. Not saying this wouldn’t be disruptive. But it’s not a project ending scenario.
  - christophilus 3y ago
    In this context, it would break a crap ton of Go modules, though. That’s the point, and git decentralization has nothing to do with it, unfortunately.
    - hnlmorg 3y ago
      As some who writes a lot of Go and thus has actually had to deal with this problem already: the hard part is finding a new source for the module. Updating your project to point to the new module takes around two minutes tops. But finding that module is the hard part. However this isn’t a uniquely Go problem. You have the same problem when switching to a new module in any language and the reasons you’d struggle is the same: because the existing module has been abandoned. If it hadn’t been abandoned then it’s very easy to find the new git repo and thus update your Go project. > git decentralization has nothing to do with it, unfortunately. It has everything to do with it. You have a local copy of the repo on your development machine and thus can throw a new mirror up if you need to. All you lose is any issue tracking and existing maintainers. But if you’re having to resort to this, those maintainers have likely already abandoned that module already.

janosdebugs 3y ago

One could argue that if the personal website goes away, you should be taking a hard look at that dependency anyway as it may have become unmaintained. Also, you can use vendoring if this is a concern.

ncjcuccy6 3y ago

Did the article somehow suggest GitHub.com might expire?

janosdebugs 3y ago
No, the article suggested that when hosting a Go package on your private domain that domain might expire. However, most Go packages are published as the module name being github.com/author/packagename, in which case domain expiry is not a problem, but you need to keep a hold of the account.
skywhopper 3y ago
The risk with GitHub is more likely that the source account of the library would be removed for any of a hundred reasons.

mort96 3y ago

I was once unable to build some Go software because some random individual's personal git hosting website was down. It's sadly not only gitlab or gitlab; at least that would've limited the amount of single points of failure.

assbuttbuttass 3y ago
Downloads will typically be cached by a module proxy, which can protect against downtime on the hosting site https://go.dev/ref/mod#goproxy-protocol https://go.dev/ref/mod#goproxy-protocol

mrweasel 3y ago

> Then domain name expiration isn’t a problem Unless Github or Gitlab goes out of business. Github might not be much of an issue, but what is some shifty company buys Gitlab during the next financial crisis? Github has Microsoft money, so I wouldn't be to concerned, but even yanking Gitlab could break an insane amount of modules in one go. Having modules distributed among many domains reduce the chances of a large scale issue, for the cost of many small problems.

weego 3y ago
If github just falls out of existence as a business with no warning I think go module issues will be just one of an impossibly long list of issues we'll all have
hnlmorg 3y ago
As much as GitHub might try to convince people otherwise, Git is a decentralised version control system. Which means if a cloud git service goes offline tomorrow, anyone who already cloned that repo still has a verbatim copy of the code that can seed a new upstream source. Not saying this wouldn’t be disruptive. But it’s not a project ending scenario.
- christophilus 3y ago
  In this context, it would break a crap ton of Go modules, though. That’s the point, and git decentralization has nothing to do with it, unfortunately.
  - hnlmorg 3y ago
    As some who writes a lot of Go and thus has actually had to deal with this problem already: the hard part is finding a new source for the module. Updating your project to point to the new module takes around two minutes tops. But finding that module is the hard part. However this isn’t a uniquely Go problem. You have the same problem when switching to a new module in any language and the reasons you’d struggle is the same: because the existing module has been abandoned. If it hadn’t been abandoned then it’s very easy to find the new git repo and thus update your Go project. > git decentralization has nothing to do with it, unfortunately. It has everything to do with it. You have a local copy of the repo on your development machine and thus can throw a new mirror up if you need to. All you lose is any issue tracking and existing maintainers. But if you’re having to resort to this, those maintainers have likely already abandoned that module already.