Go 코드를 GitHub에 묶지 마세요
Don't couple your Go code to GitHub
Go는 import 경로에 git 호스팅 주소를 쓰는 관행 때문에 코드가 특정 플랫폼에 종속된다. 한 회사는 GitLab, GitHub, Azure DevOps를 동시에 운영하며 비용을 낭비했다. 저자는 go.iain.rocks 같은 커스텀 도메인을 사용해 호스팅을 자유롭게 옮기는 해법을 제시하고, Nginx와 go-import 메타태그 설정 예시를 공유한다.
코드가 GitHub에 문자 그대로 묶여버리는 결과를 낳는다. 완전히 미친 소리처럼 들리지만, 이는 Go 커뮤니티에서 사실상 기본값이다.
HN 토론
137- jerf
이건 지나치게 구체적인 것의 혼란 속에 숨어 있다. 문제는 일반적이다. 패키지에 이름을 붙이려면, 어떤 종류의 네임스페이스 안에 있어야 한다. 우주가 우리 모두가 호소할 수 있는 추상적인 주변 "네임스페이스"를 제공하지 않으므로, 모든 네임스페이스는 인간의 구성물이다. 인간의 구성물이기에, 실패할 수 있다.
이 용어로 보면, 이 글은 기본적으로 "이 네임스페이스는 실패할 수 있다! 해결책은 다른 것을 사용하는 것이다!"라고 말하는 셈이다.
하지만 그건 아무 데도 도달하지 못한다. 왜냐하면 새 네임스페이스도 실패할 수 있기 때문이다. 사실 네임스페이스로서 "github.com의 DNS와 호스팅"보다 더 빨리 실패할 것이 거의 확실하다.
소프트웨어 릴리스를 실패할 수 없는 네임스페이스에 묶는 해결책은 없다. 왜냐하면 실패할 수 없는 네임스페이스는 존재하지 않기 때문이다. 당신이 좋아하는 언어가 DNS를 사용하든, 중앙에서 축복받은 저장소를 가지고 있든, 언어 자체와 함께 축복받은 패키지 이름 목록을 배포하든, 그 밖의 무엇이든 상관없다. 네임스페이스는 실패할 수 있다.
따라서 정말로 할 수 있는 유일한 일은 실패에 대해 회복력 있게 대처하는 것이며, 여러 면에서 회복력에 대한 유일한 실용적 해결책은 단지 미래에 누군가가 네임스페이스 실패로 인해 패키지를 얻는 데 문제가 생기면, 당신의 코드가 영원히 사라진 상태에서 눈물 웅덩이로 무력하게 녹아내리지 않고, 대신 미래의 그 사람이 이 완벽하게 해결 가능한 문제를 해결할 것이라고 가정하는 것이다.
- rot256
Go의 패키지 관리는 항상 상당히 임시방편처럼 느껴졌다. 문제 중 하나는 "무엇인가"와 "어디에 있는가" 사이의 혼동이다. 초기에는 패키지의 다른 버전을 가질 방법조차 없었고, 그 명분은 그냥 인터페이스를 고정하고 영원히 안정적으로 유지하라는 것이었다. 또한 "의존성 잠금" 방법도 없어서 빌드 시에는 그 저장소가 제공하는 것을 그대로 받았다. 그 이후로 나아졌지만, 패키지 시스템을 "성장"시킨 결과로 여전히 약간의 어설픔이 있다.
- thih9
> 내 생각에, Go를 사용하는 모든 상업 소프트웨어 개발 팀은 내부 라이브러리와 패키지의 네임스페이싱을 위해 커스텀 도메인을 사용해야 한다.
위에서 "Go"를 빼겠다. 즉, 다른 스택에도 같은 논리가 적용된다고 생각한다.
코드 주석에 GitHub 도메인 링크를 사용하는 것조차 장기적으로 문제가 된다. 예를 들어 마이그레이션이 일어나면 그 링크들이 아무 데도 가리키지 않게 된다.
- dewey
> 즉, git 호스팅을 GitLab으로 옮기면 코드를 변경해야 한다!
go.mod 파일에 "replace github.com/example/example => gitlab.com/example/example"를 사용하면 모든 것이 계속 작동한다. 별로 중요하지도 않은 일에 대한 매우 시기상조의 최적화처럼 보인다.
- farthest
그럼 도메인 제공자가 인수되고 OSS 프로젝트의 도메인이 경매에 부쳐져 탈취되면 어떻게 되는가? 이건 끝없이 거북이 등껍질 위에 거북이가 있는 것처럼 보인다..
- p4bl0
맞다, 하지만 사용 중인 도메인 이름을 조심하라. VeriSign이 수천 개의 다른 도메인과 함께 당신의 도메인 이름을 일방적으로 삭제하기로 결정할 수 있고[1], 그러면 다시 원점으로 돌아간다…
- unscaled
> Go의 좋은 기능 중 하나는 코드를 가져올 위치로 코드의 네임스페이스를 지정한다는 것이다.
그런데 글의 나머지 부분은 왜 이것이 실제로는 좋은 기능이 아닌지 설명한다.
해결 불가능하다고는 생각하지 않지만, 이것은 Go가 다르게 하기로 결정하고 팬들에게 이것이 대단한 아이디어이며 다른 모든 언어는 잘못하고 있다고 설득한 그런 작은 것 중 하나다. 몇 가지 걸림돌이 나타난 후, 공식 패키지 이름을 갖는 것의 장점이 있다는 것을 인정하는 대신, 이제는 모든 사람이 GitHub에 호스팅된 패키지를 위해 트래픽을 제공하도록 nginx 서버나 Go Vanity URLs 포워더로 자체 커스텀 도메인을 설정해야 한다고 말한다.
- st3fan
회사가 망하고 도메인이 공중에 떠돌 때 정말 좋다. 다음으로 그 도메인을 낚아채는 사람이 다른 사람들이 새로 의존하게 된 소스 코드를 차지하게 된다. 우리는 이미 다른 생태계에서 이런 일을 여러 번 보았다. 매우 나쁜 상황이다.
패키지를 자신의 도메인 아래로 옮기라는 것은 나쁜 조언이다. 당신은 도메인 비용을 계속 지불하는 데 있어 Microsoft만큼 잘할 수 없을 것이다. 인생에 보장은 없지만, 회사가 망할 때 그 도메인이 당신이 마지막으로 생각할 것이라는 점은 보장한다.