Go: cmd/go: Go 도구 모음에 패키지 버전 지원 추가

자주 묻는 질문

이 문제 의견은 아래 토론이나 다른 토론에서 가장 자주 묻는 질문에 대한 답변입니다. 토론의 다른 질문은 다음 문제 의견에 있습니다.

제안이 " dep 사용"이 아닌 이유는 무엇입니까?

거의 2년 전 이 제안으로 이어진 여정이 시작될 때 우리 모두는 Ruby의 Bundler와 Rust의 Cargo가 예시한 패키지 버전 관리 접근 방식을 따르는 것이라고 믿었습니다. 태그가 지정된 의미 체계 버전, 손으로 편집한 종속성 제약 파일 매니페스트라고 하는 별도의 기계 생성 전이 종속성 설명(잠금 파일), 매니페스트를 충족하는 잠금 파일을 계산하기 위한 버전 솔버, 버전 관리 단위로서의 리포지토리. Dep은 이 대략적인 계획을 거의 정확하게 따르고 원래 go 명령 통합을 위한 모델 역할을 하도록 의도되었습니다. 그러나 Bundler/Cargo/Dep 접근 방식의 세부 사항과 특히 go 명령에 내장된 Go에 대한 의미를 더 많이 이해할수록 Go 팀의 다른 사람들과 이러한 세부 사항에 대해 더 많이 논의할수록 몇 가지 세부 사항은 바둑에 점점 덜 적합해 보였습니다. 제안은 개발자가 이해하고 사용하기 더 쉬운 시스템을 제공하기 위해 이러한 세부 사항을 조정합니다. 변경하려는 특정 세부정보에 대한 자세한 내용과 제안을 발표하는 블로그 게시물 에 대한 자세한 내용은 제안의 근거 섹션 을 참조하세요.

주요 버전 번호가 가져오기 경로에 표시되어야 하는 이유는 무엇입니까?

시스템의 나머지 부분을 극적으로 단순화하는 가져오기 호환성 규칙 을 따르기 위해. 또한 가져오기 호환성 규칙에 대한 동기와 정당성에 대해 자세히 설명 하는 제안을 발표하는 블로그 게시물 을 참조하십시오.

주요 버전 v0, v1이 가져오기 경로에서 생략된 이유는 무엇입니까?

v1은 두 가지 이유로 가져오기 경로에서 생략됩니다. 첫째, 많은 개발자가 v1에 도달하면 절대 변경하지 않는 패키지를 만들 것입니다. 이는 우리가 처음부터 권장한 것입니다. 우리는 모든 개발자가 v2를 릴리스할 의사가 없을 때 명시적인 v1을 갖도록 강요받아야 한다고 생각하지 않습니다. v1은 그냥 노이즈가 됩니다. 해당 개발자가 결국 v2를 만들면 기본 v1과 구별하기 위해 추가 정밀도가 시작됩니다. v1을 모든 곳에 배치하기 위한 가시적 안정성에 대한 좋은 주장이 있으며, 우리가 시스템을 처음부터 설계하는 경우에는 그것이 거의 결정적일 수 있습니다. 그러나 기존 코드의 무게는 v1을 생략하는 데 유리하게 균형을 유지합니다.

v0은 semver 에 따르면 해당 버전에 대한 호환성 보장이 전혀 없기 때문에 가져오기 경로에서 생략됩니다. 명시적 v0 요소를 요구하는 것은 호환성을 보장하는 데 거의 도움이 되지 않습니다. 완전히 정확하려면 v0.1.2라고 말해야 합니다. 라이브러리를 업데이트할 때마다 모든 가져오기 경로를 업데이트해야 합니다. 그건 과한 것 같습니다. 대신 개발자가 의존하는 모듈 목록을 보고 찾은 v0.xy 버전에 대해 적절하게 주의하기를 바랍니다.

이는 가져오기 경로에서 v0과 v1을 구별하지 않는 효과가 있지만 일반적으로 v0은 v1으로 이어지는 일련의 주요 변경 사항이므로 v1을 v0과 구별할 필요가 없는 것이 아니라 해당 중단 시퀀스의 마지막 단계로 취급하는 것이 합리적입니다. . @Merovius 가 말했듯이 (https://github.com/golang/go/issues/24301#issuecomment-376213693):

v0.x를 사용하면 v0.(x+1)이 강제로 코드를 수정할 수 있음을 인정하게 됩니다. v0.(x+1)을 대신 v1.0이라고 하면 왜 문제가 되나요?

마지막으로, 주 버전 v0 및 v1을 생략하는 것은 선택 사항이 아닌 필수 사항이므로 각 패키지에 대한 단일 정규 가져오기 경로가 있습니다.

마스터에서 계속 작업하는 대신 v2용 새 분기를 만들어야 하는 이유는 무엇입니까?

새 분기를 만들 필요가 없습니다. vgo 모듈 포스트는 불행히도 "주요 분기" 저장소 레이아웃에 대한 논의에서 그런 인상을 줍니다. 그러나 vgo는 분기에 신경 쓰지 않습니다. 태그만 조회하고 태그가 가리키는 특정 커밋을 확인합니다. 마스터에서 v1을 개발하는 경우 v1이 완전히 완료되었다고 결정하고 마스터에서 v2 커밋을 시작하려는 경우 괜찮습니다. v2.xy 태그로 마스터에 태그 지정을 시작합니다. 그러나 일부 사용자는 v1을 계속 사용할 것이며 때때로 사소한 v1 버그 수정을 발행할 수 있습니다. 적어도 v2용 마스터를 사용하기 시작하는 시점에서 해당 작업에 대한 새 v1 분기를 분기할 수 있습니다.

최소 버전 선택으로 인해 개발자가 중요한 업데이트를 받지 못하게 되지 않습니까?

이것은 일반적인 두려움이지만 반대의 일이 발생하면 정말 생각합니다. https://research.swtch.com/vgo-mvs 의 "업그레이드 속도" 섹션 인용:

최소 버전 선택이 각 종속성의 최소 허용 버전을 사용한다는 점을 감안할 때 이것이 매우 오래된 패키지 복사본을 사용하게 되어 불필요한 버그나 보안 문제가 발생할 수 있다고 생각하기 쉽습니다. 그러나 실제로는 반대가 발생할 것이라고 생각합니다. 허용되는 최소 버전은 모든 제약 조건의 최대값이므로 빌드의 모든 모듈에서 사용할 수 있는 제어 수단 중 하나는 새 버전을 강제로 사용하는 기능입니다. 그렇지 않으면 사용되는 것보다 종속성이 있습니다. 최소한의 버전 선택을 하는 사용자는 Cargo와 같은 보다 공격적인 시스템을 사용하는 친구만큼 최신 상태의 프로그램을 사용하게 될 것입니다.

예를 들어, 여러분이 gopkg.in/yaml.v2와 같은 매우 일반적인 모듈에 의존하는 소수의 다른 모듈에 의존하는 프로그램을 작성한다고 가정합니다. 프로그램의 빌드는 모듈에서 요청한 것과 소수의 종속성 중에서 최신 YAML 버전을 사용합니다. 단 하나의 성실한 종속성만으로도 빌드가 다른 많은 종속성을 업데이트하도록 할 수 있습니다. 이것은 앞서 언급한 Kubernetes Go 클라이언트 문제의 반대입니다.

어쨌든 최소 버전 선택은 반대 문제를 겪을 것입니다. 이 "최소값의 최대값" 대답은 종속성을 너무 빨리 앞으로 강제하는 래칫 역할을 합니다. 그러나 실제로는 종속성이 적절한 속도로 앞으로 나아갈 것이며 결국 Cargo 및 친구들보다 느릴 것입니다.

"올바른 양만큼 느리게"라는 말은 업그레이드가 요청했을 때만 발생하고 요청하지 않았을 때는 발생하지 않는 주요 속성을 언급한 것입니다. 이는 코드가 변경될 것으로 예상하고 테스트, 디버그 등을 할 준비가 되었을 때만(잠재적으로 예기치 못한 방식으로) 변경된다는 것을 의미합니다.

@Merovius의 응답 https://github.com/golang/go/issues/24301#issuecomment -375992900도 참조하세요.

$GOPATH가 더 이상 사용되지 않는 경우 다운로드한 코드는 어디에 있습니까?

체크아웃하고 작업하고 수정하는 코드는 다른 모든 개발자 도구와 마찬가지로 파일 시스템의 어느 곳에나 저장할 수 있습니다.

Vgo는 다운로드한 소스 코드를 보관하고 바이너리를 설치하기 위해 약간의 공간이 필요하며, 이를 위해 Go 1.9에서 기본적으로 $HOME/go로 설정되는 $GOPATH를 계속 사용합니다. 따라서 개발자는 이러한 파일이 다른 디렉토리에 있기를 원하지 않는 한 $GOPATH를 설정할 필요가 없습니다. 바이너리 설치 위치만 변경하려면 $GOBIN을 설정할 수 있습니다(항상 그렇듯이).

// import 댓글을 왜 도입합니까?

하지 않았다. 그것은 기존의 관습 이었습니다. 둘러보기에서 해당 예제의 요점은 go.mod 가 있는 경우 가져오기 주석에서 올바른 모듈 경로를 추론할 수 있는 방법을 보여주는 것입니다. 모든 프로젝트 go.mod 파일을 사용하면 가져오기 주석이 완전히 중복되고 아마도 더 이상 사용되지 않을 것입니다.

토론 요약(최종 업데이트 2017-04-25)

이 문제 의견에는 아래의 토론 내용이 요약되어 있습니다.

마이그레이션을 어떻게 처리할 수 있습니까?

[ https://github.com/golang/go/issues/24301#issuecomment -374739116 @ChrisHines 작성.]

응답 https://github.com/golang/go/issues/24301#issuecomment -377529520 @rsc. 원래 제안은 호환성이 중요할 때 하위 디렉토리로 이동하는 작성자가 마이그레이션을 처리한다고 가정하지만 물론 동기가 잘못되었습니다. 호환성은 작가 이동에 거의 영향을 미치지 않는 사용자에게 가장 중요합니다. 그리고 이전 버전에는 도움이 되지 않습니다. 링크된 주석(현재 #25069)은 모듈 인식 코드를 사용하고 빌드할 수 있도록 이전 "구축"에 대한 최소한의 변경을 제안합니다.

싱글톤 등록을 어떻게 처리할 수 있습니까?

[ https://github.com/golang/go/issues/24301#issuecomment -374791885 @jimmyfrasche 작성.]

응답 https://github.com/golang/go/issues/24301#issuecomment -377527249 by @rsc. 완전히 다른 모듈 간의 싱글톤 등록 충돌(예: 동일한 경로의 http.Handle)은 제안의 영향을 받지 않습니다. 단일 모듈의 서로 다른 주요 버전 간의 충돌의 경우 작성자는 일반적으로 v1을 v2로 호출하여 조정될 것으로 예상하는 서로 다른 주요 버전을 작성한 다음 요구 사항 주기를 사용하여 v2가 그렇지 않은 이전 v1과 함께 사용되지 않도록 할 수 있습니다. 조정에 대해 알지 못합니다.

버전이 지정된 명령을 어떻게 설치해야 합니까?

[ https://github.com/golang/go/issues/24301#issuecomment -375106068 by @leonklingele.]

응답 https://github.com/golang/go/issues/24301#issuecomment -377417565 @rsc. 간단히 말해 go get을 사용합니다. 우리는 여전히 설치 위치로 $GOPATH/bin을 사용합니다. $GOPATH는 이제 $HOME/go로 기본 설정되므로 명령은 $HOME/go/bin으로 끝나고 $GOBIN은 이를 재정의할 수 있습니다.

가져오기 경로에서 v0, v1이 생략된 이유는 무엇입니까? 왜 다른 사람들이 나타나야 합니까? v0, v1이 절대 나타나지 않아야 하는 이유는 무엇입니까?

[ https://github.com/golang/go/issues/24301#issuecomment -374818326 @justinian 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -374831822 @jayschwa 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -375437150 @mrkanister 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -376093912 @mrkanister 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -376135447 @kaikuehne 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -376141888 @kaikuehne 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -376213693 @Merovius 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -376247926 @kaikuehne 작성.]

위의 FAQ에 추가되었습니다.

제안서에 zip 파일이 언급된 이유는 무엇입니까?

[ https://github.com/golang/go/issues/24301#issuecomment -374839409 @nightlyone 작성.]

생태계는 구체적인 교환 형식을 정의함으로써 이익을 얻을 것입니다. 그러면 프록시 및 기타 도구가 활성화됩니다. 동시에 우리는 버전 제어의 직접적인 사용을 포기하고 있습니다( 이 게시물 상단의 근거 참조). 이 두 가지 모두 특정 형식을 설명하는 데 동기를 부여합니다. 대부분의 개발자는 zip 파일에 대해 전혀 생각할 필요가 없습니다. godoc.org와 같은 것을 구축하지 않는 한 개발자는 내부를 볼 필요가 없습니다.

zip 대 tar에 대한 #24057도 참조하십시오.

주요 버전을 가져오기 경로에 넣으면 DRY를 위반하지 않습니까?

[ https://github.com/golang/go/issues/24301#issuecomment -374831822 @jayschwa 작성.]

아니요, 가져오기의 의미는 go.mod 파일을 참조하지 않고도 이해할 수 있어야 하기 때문입니다. go.mod 파일은 세부 사항만 지정하고 있습니다. 블록 인용에서 시작 하는 제안서의 의미론적 가져오기 버전 섹션의 후반부를 참조하십시오.

또한 너무 많이 말리면 깨지기 쉬운 시스템이 됩니다. 중복성은 좋은 것일 수 있습니다. 따라서 "DRY 위반"(즉, 제한된 반복)이 항상 나쁜 것은 아닙니다. 예를 들어 우리는 디렉토리의 모든 .go 파일에 패키지 절을 넣습니다. 단 하나가 아니라. 이는 초기에 정직한 실수를 포착했고 나중에 외부 테스트 패키지(패키지 x 대 패키지 x_test)를 구별하는 쉬운 방법으로 바뀌었습니다. 균형을 맞춰야 합니다.

의사 버전의 타임스탬프에 어떤 시간대가 사용됩니까?

[ https://github.com/golang/go/issues/24301#issuecomment -374882685 by @tpng.]

UTC. 또한 의사 버전을 직접 입력할 필요가 없습니다. git 커밋 해시(또는 해시 접두사)를 입력하면 vgo가 적절한 의사 버전을 계산하고 대체합니다.

vgo가 C 또는 프로토콜 버퍼와 같은 비 Go 종속성을 처리합니까? 생성된 코드?

[ https://github.com/golang/go/issues/24301#issuecomment -374907338 @AlexRouSg.]
[ https://github.com/golang/go/issues/24301#issuecomment -376606788 @stevvooe 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -377186949 by @nim-nim.]

Non-Go 개발은 계속해서 go 명령의 목표가 아니므로 C 라이브러리 관리 등을 지원하지 않으며 프로토콜 버퍼에 대한 명시적인 지원도 없을 것입니다.

그렇긴 하지만 Go에서 프로토콜 버퍼를 사용하는 것이 너무 어렵다는 점을 확실히 이해하고 있으며 별도로 해결되었으면 합니다.

보다 일반적으로 생성된 코드의 경우 실제 언어 간 빌드 시스템이 답입니다. 특히 모든 사용자가 올바른 생성기를 설치할 필요가 없기 때문입니다. 작성자가 생성기를 실행하고 결과를 확인하는 것이 좋습니다.

최소 버전 선택으로 인해 개발자가 중요한 업데이트를 받지 못하게 되지 않습니까?

[ https://github.com/golang/go/issues/24301#issuecomment -375090551 @TocarIP 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -375985244 @nim-nim.]
[ https://github.com/golang/go/issues/24301#issuecomment -375992900 @Merovius 작성]

FAQ에 추가되었습니다.

### 마스터를 사용하여 v1을 개발한 다음 v2를 개발하는 데 재사용할 수 있습니까?

[ https://github.com/golang/go/issues/24301#issuecomment -375248753 @mrkanister 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -375989173 @aarondl.]

예. FAQ에 추가되었습니다.

이에 대한 일정은 어떻게 됩니까?

[ https://github.com/golang/go/issues/24301#issuecomment -375415904 @flibustenet 작성.]

https://github.com/golang/go/issues/24301#issuecomment -377413777 @rsc의 응답입니다. 간단히 말해서 목표는 Go 1.11에서 "기술 미리보기"를 시작하는 것입니다. 작업은 동결 후에도 몇 주 동안 계속될 수 있지만 그 이상은 아닙니다. 제안이 수락됨으로 표시되고 cmd/go의 개발 사본이 업데이트될 때까지 찾을 수 있는 모든 라이브러리에 go.mod를 추가하는 PR을 보내지 마십시오.

이전 버전과 호환되지 않는 보안 변경을 수행하려면 어떻게 해야 합니까?

[ https://github.com/golang/go/issues/24301#issuecomment -376236546 by @buro9.]

https://github.com/golang/go/issues/24301#issuecomment -377415652 @rsc의 응답입니다. 요컨대, Go 1 호환성 지침 은 보안상의 이유로 주요 버전 충돌을 방지하기 위해 변경 사항을 깨는 것을 허용하지만 기존 코드가 가능한 한 많이 작동하도록 유지하는 방식으로 그렇게 하는 것이 항상 가장 좋습니다. 예를 들어, 기능을 제거하지 마십시오. 대신, 부적절하게 호출된 경우에만 함수를 패닉 또는 log.Fatal로 만듭니다.

하나의 저장소가 하위 디렉토리(예: v2, v3, v4)에 다른 모듈을 보유하는 경우 vgo가 다른 커밋에서 혼합 및 일치시킬 수 있습니까?

[ https://github.com/golang/go/issues/24301#issuecomment -376266648 @jimmyfrasche 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -376270750 @AlexRouSg.]

예. 각 버전 태그를 전체 저장소의 하나의 하위 트리에만 해당하는 것으로 취급하고 각 결정에 대해 다른 태그(따라서 다른 커밋)를 사용할 수 있습니다.

프로젝트에서 semver를 오용하면 어떻게 되나요? 가져오기 경로에서 부 버전을 허용해야 합니까?

[ https://github.com/golang/go/issues/24301#issuecomment -376640804 @pbx0.]
[ https://github.com/golang/go/issues/24301#issuecomment -376645212 @powerman 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -376650153 by @pbx0.]
[ https://github.com/golang/go/issues/24301#issuecomment -376660236 @powerman 작성.]

@powerman 이 언급했듯이, 우리는 분명히 API 일관성 검사기를 제공하여 프로젝트가 분명히 깨는 변경을 릴리스하려고 할 때 최소한 프로젝트에 알릴 수 있어야 합니다.

빌드에 패키지가 두 개 이상 있는지 확인할 수 있습니까?

[ https://github.com/golang/go/issues/24301#issuecomment -376640804 @pbx0.]

가장 쉬운 방법은 결과 바이너리에 goversion -m 을 사용하는 것입니다. 바이너리를 빌드하지 않고 동일한 것을 표시하는 go 옵션을 만들어야 합니다.

프록시 대 벤더, 특히 오픈 소스 대 엔터프라이즈에 대한 vgo 의존성에 대한 우려.

[ https://github.com/golang/go/issues/24301#issuecomment -376925845 @joeshaw 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -376936614 @kardianos 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -376947621 @Merovius 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -376979054 @joeshaw 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -376988873 @jamiethermo 작성.]
[ https://github.com/golang/go/issues/24301#issuecomment -377134575 @Merovius 작성]

응답: [ https://github.com/golang/go/issues/24301#issuecomment -377411175 by @rsc.] 프록시와 공급업체가 모두 지원됩니다. 프록시는 엔터프라이즈에 매우 중요하고 벤더는 오픈 소스에 매우 중요합니다. 우리는 또한 신뢰할 수 있는 미러 네트워크를 구축하기를 원하지만 vgo가 go가 된 후에만 가능합니다.

GOPATH 시맨틱에 따른 프로토빌드에 대한 우려.

[ https://github.com/golang/go/issues/24301#issuecomment -377601170 @stevvooe 작성.]

응답 [ https://github.com/golang/go/issues/24301#issuecomment -377602765 by @rsc]에서 새 문제에 대한 자세한 내용을 요청했지만 해당 문제는 제출되지 않은 것 같습니다.

특별한 vgo-v1-lock 태그를 추가하라는 제안입니다.

[ https://github.com/golang/go/issues/24301#issuecomment -377662150 by @kybin.]

처음에는 매력적으로 보이지만 아마도 맡을 가치가 없는 특수한 경우로 이어집니다. https://github.com/golang/go/issues/24301#issuecomment -384344659의 전체 응답.

벤더링 없이 어떻게 깊은 종속성을 패치합니까?

[ https://github.com/golang/go/issues/24301#issuecomment -378255833 @chirino 작성.]

응답 [ https://github.com/golang/go/issues/24301#issuecomment -378261916 by @kardianos.] 바꾸기 지시문을 사용합니다.

모듈 이름이 변경되면 어떻게 해야 합니까?

[ https://github.com/golang/go/issues/24301#issuecomment -379020339 @jimmyfrasche 작성.]

응답 [ https://github.com/golang/go/issues/24301#issuecomment -379307176 @rsc.]
이것은 vgo 제안이 직접 해결하려고 시도하지 않는 실제 기존 문제이지만 분명히 우리는 결국 해결해야 합니다. 코드가 사라지는 것에 대한 답은 캐싱 프록시(미러)와 함께 이를 신뢰할 이유가 있는 것입니다. 그것이 미래의 일이다. (또는 원하는 경우 최상위 프로젝트에서 공급업체를 사용하십시오.) 코드 이동에 대한 대답은 유형 별칭이 유형 리디렉션인 것처럼 모듈 또는 패키지 리디렉션의 명시적 개념을 추가하는 것입니다. 그것은 미래의 일이기도 하다.

로컬 Git 서버에 연결하는 것은 어떻습니까?

[ https://github.com/golang/go/issues/24301#issuecomment -383168012 by @korya.]

직접 자식 액세스가 계획에 다시 추가되었습니다. #24915를 참조하십시오.

바이너리 전용 패키지는 어떻습니까?

[ https://github.com/golang/go/issues/24301#issuecomment -382793364 @sdwarwick 작성.]

바이너리 전용 패키지는 GOPATH/pkg에 대역 외 설치와 같은 제한된 상황에서만 지원되었습니다. Go get은 바이너리 전용 패키지 가져오기 및 설치를 지원한 적이 없으며 앞으로도 계속 지원하지 않을 것입니다. 바이너리 전용 패키지는 하나의 특정 컴파일러와 하나의 특정 종속성 복사본에서만 작동하므로 지원될 수 있는 정도가 심각하게 제한됩니다. 정답은 거의 항상 소스 코드를 대신 사용하는 것입니다.

go.mod 파일에서 path@version 구문을 사용해야 합니까?

[ https://github.com/golang/go/issues/24301#issuecomment -382791513 @sdwarwick 작성.]

#24119 입니다. 처음에는 좋은 생각처럼 보였지만 신중하게 고려한 후에는 아니었습니다.

.

.

https://golang.org/cl/101678 에서 이 문제를 언급 변경: design: add 24301-versioned-go

이 제안은 인상적이고 나는 그것에 관한 모든 것이 가장 마음에 듭니다. 그러나 메일링 리스트에 다음과 같은 우려 사항을 올렸지만 응답을 받지 못했습니다. 그동안 나는 vgo에 대한 Gophers slack 채널에서 다른 사람들이 제기한 이 문제를 보았지만 거기에서도 만족스러운 답변을 보지 못했습니다.

보낸 사람: https://groups.google.com/d/msg/golang-dev/Plc42fslQEk/rlfeNlazAgAJ

vgo 이전 세계와 vgo 세계 사이의 마이그레이션 경로가 나빠지는 것이 가장 걱정입니다. 원활한 마이그레이션 경로가 없으면 Go 커뮤니티에 큰 고통을 줄 위험이 있다고 생각합니다. 분명히 마이그레이션은 전체 커뮤니티에서 원자적일 수 없지만 지금까지 vgo에 대해 작성한 모든 내용을 이해했다면 기존의 널리 사용되는 패키지를 pre-vgo 도구와 post 모두에서 사용할 수 없는 상황이 있을 수 있습니다. -vgo 도구.

특히, 주요 버전 >= 2로 태그가 지정된 릴리스가 이미 있는 기존 패키지는 go.mod 파일이 있고 /vN 증강 가져오기 경로를 사용하여 가져올 때까지 vgo에서 작동하지 않을 것이라고 생각합니다. 그러나 저장소에 이러한 변경 사항이 적용되면 vgo 이전 패키지 사용이 중단됩니다.

이것은 다이아몬드 중간에 있는 두 형제 패키지가 공통 v2+ 패키지를 가져오는 다른 종류의 다이아몬드 가져오기 문제를 생성하는 것으로 보입니다. vgo를 사용하든 pre-vgo 도구를 사용하든 다이아몬드 맨 위에 있는 패키지가 빌드할 수 없는 상태가 되는 것을 방지하기 위해 형제 패키지가 vgo 가져오기 경로를 원자적으로 채택해야 하는지 걱정됩니다.

이 시나리오에서 마이그레이션 경로를 설명하는 것은 아직 본 적이 없습니다.

제안서에는 다음과 같이 명시되어 있습니다.

모듈 인식 빌드는 v0 또는 v1 시맨틱 버전으로 태그가 지정된 비모듈 인식 패키지(go.mod 파일이 있는 트리 외부에 있는 패키지)를 가져올 수 있습니다. 또한 v0.0.0-yyyymmddhhmmss-commit 형식의 "의사 버전"을 사용하여 특정 커밋을 참조할 수도 있습니다. 의사 버전 형식을 사용하면 태그가 지정되지 않은 커밋과 v2 이상에서 의미 체계 버전으로 태그가 지정되지만 의미 체계 가져오기 버전 관리 규칙을 따르지 않는 커밋을 참조할 수 있습니다.

그러나 비 모듈 인식 패키지가 전이 종속성 >= v2가 있는 모듈 인식 패키지를 가져올 방법이 없습니다. 이는 아직 해결되지 않은 방식으로 생태계 분열을 일으키는 것으로 보입니다. 패키지가 >= v2인 모듈 인식 종속성이 있으면 모든 종속 항목도 vgo를 채택하여 빌드 작동을 유지하도록 강제하는 것으로 보이는 전이 종속성 어딘가에 v2가 있습니다.

업데이트: https://github.com/golang/go/issues/24454 도 참조하세요.

Go 프로젝트는 프로젝트 시작부터 이 규칙을 권장했지만 이 제안은 더 많은 것을 제공합니다. 패키지 사용자에 의한 업그레이드는 패키지 작성자가 가져오기 호환성 규칙을 따르는 범위에서만 성공하거나 실패합니다.

이것이 무엇을 의미하고 현재 상황에서 어떻게 변화하는지 나에게는 불분명합니다. 이것은 현재 상황도 설명하는 것 같습니다. 이 규칙을 어기면 업그레이드와 go-get이 실패합니다. AIUI는 실제로 변경되는 사항이 없으며 적어도 "더 많은 치아"에 대한 언급을 제거하는 것이 좋습니다. 물론 이 단락이 파손을 처벌/방지하기 위한 추가 메커니즘이 있음을 의미하지 않는 한?

이는 동일한 패키지의 여러 주요 버전이 결국 이를 수행할 수 있기 때문에 초기화 중에 다른 패키지에 자신을 등록하는 데이터베이스 드라이버 및 이미지 형식과 같은 것들에도 영향을 미칩니다. 그것이 어떤 영향을 미칠지는 나에게 분명하지 않습니다.

주 버전이 v0 또는 v1이면 버전 번호 요소를 생략해야 합니다. 그렇지 않으면 포함되어야 합니다.

왜 이런거야? 링크된 게시물에서는 이것이 개발자가 현재 변경 사항을 만들 때 대체 경로를 생성하기 위해 수행하는 작업이라는 근거만 볼 수 있습니다. . 새로운 방식으로 전환하는 경우 새로운 vgo 지원 패키지에 v0 또는 v1 가 포함되도록 허용하고 권장(또는 의무화)하는 것은 어떻습니까? 버전이 없는 경로는 혼란의 기회일 뿐입니다. (vgo 스타일 패키지인가요? 모듈 경계는 어디인가요? 등)

나는 일반적으로 제안을 좋아하지만 가져오기 경로에 주요 버전을 요구하는 것에 매달렸습니다.

1. go.mod 에서 주 버전을 이미 알 수 있는 경우 DRY 원칙을 위반합니다. 둘 사이에 불일치가 있는 경우 어떤 일이 발생하는지 이해하는 것도 직관하기 어렵습니다.
2. v0 및 v1 가 부재하도록 허용하는 불규칙성도 직관적이지 않습니다.
3. 종속성을 업그레이드할 때 모든 가져오기 경로를 변경하는 것은 잠재적으로 지루할 수 있습니다.

moauth 예제와 같은 시나리오는 실행 가능해야 하지만 더 일반적인 시나리오를 위해 단순하게 유지하는 비용을 들이지 않기를 바랍니다.

우선: 인상적인 작품!

나에게 완전히 불분명하고 약간 덜 지정 된 것 같습니다.

이 제안에 zip 파일이 있는 이유는 무엇입니까?

레이아웃, 제약 조건 및 여러 사용 사례(예: 생성 시기 및 수명 주기 관리 방법, 지원이 필요한 도구, 린터와 같은 도구와 상호 작용하는 방법)도 제안에서 다루지 않기 때문에 불분명합니다.

따라서 이 제안의 범위 내에서 전혀 논의하지 않으려는 경우 나중에 아직 작성되지 않은 제안을 여기에서 참조하고 zip이라는 단어를 제거하거나 제안 텍스트에서 전체 부분을 제거하는 것이 좋습니다.

나중에 이에 대해 논의하면 다른 청중이 여기에 더 잘 기여할 수 있습니다.

의사 버전(v0.0.0-yyyymmddhhmmss-commit)의 타임스탬프에 어떤 시간대가 사용됩니까?

편집하다:
https://research.swtch.com/vgo-module에 명시된 대로 UTC입니다.

@rsc C 종속성을 다룰 예정입니까?

최소 버전 선택이 핵심 변경 사항의 전파를 매우 느리게 만드는 것 같습니다. 프로젝트 A, B 및 C에서 사용하는 인기 있는 라이브러리 Foo가 있다고 가정합니다. 누군가 API를 변경하지 않고 Foo 성능을 향상시킵니다. 현재 업데이트를 받는 것은 옵트아웃 프로세스입니다. 프로젝트 A가 Foo를 제공했지만 B와 C가 제공하지 않은 경우 작성자는 A에 대한 벤더 종속성에 대한 업데이트와 함께 pr을 보내기만 하면 됩니다. 상황. 이는 보안 업데이트의 경우 더욱 문제가 됩니다. 일부 버려진/작은/별로 활동적이지 않은 프로젝트(라이브러리가 아님)가 x/crypto와 같은 이전 버전에 대한 직접적인 종속성을 선언하면 해당 프로젝트의 모든 사용자는 프로젝트가 업데이트될 때까지 잠재적으로 영원히 x/crypto의 결함에 취약합니다. 현재 이러한 프로젝트의 사용자는 최신 고정 버전을 받게 되므로 보안 상황이 악화됩니다. IIRC는 메일 목록 토론에서 이를 수정하는 방법에 대한 몇 가지 제안이 있었지만, 내가 말할 수 있는 한 이 제안에는 언급되지 않았습니다.

IIRC 메일 목록 토론에서 [보안 패치 받기]를 수정하는 방법에 대한 몇 가지 제안이 있었지만 내가 말할 수 있는 한 이 제안에는 언급되지 않았습니다.

go get -p 에 대한 언급을 참조하십시오.

go get -p에 대한 언급을 참조하십시오.

나는 그것을 보았지만 이것은 여전히 ​​옵트인 메커니즘입니다.
라이브러리가 모든 이전 릴리스를 안전하지 않은 것으로 표시하여 사용자가 go get -p를 실행하거나 안전하지 않은 라이브러리에 명시적으로 옵트인하도록 하는 방법을 생각하고 있었습니다.

오늘날 우리가 알고 있는 go get 에 대한 지원이 더 이상 사용되지 않고 결국 제거될 경우 Go 바이너리를 가져오고 설치하는 권장 방법은 무엇입니까? 프로젝트를 먼저 $#$ git clone $#$ 하고 바이너리를 설치하려면 수동 go install 가 필요합니까?
$GOPATH 가 더 이상 사용되지 않는 경우 이러한 바이너리는 어디에 설치됩니까?

@leonklingele : 내 이해에 따르면 go get 는 더 이상 사용되지 않습니다.
자동 및 투명한 버전 관리 기능으로 향상됩니다. 프로젝트가 태그가 지정되지 않은 프로젝트에 종속된 경우 마스터를 가져와 이 정확한 버전에서 "공급업체"로 만듭니다.
다시 말하지만, vgo에 대한 약간의 읽기에서 내 자신의 이해. 아직 완전히 이해하는 단계입니다.

이것이 제안서의 다음 문장을 기반으로 하여 일반적으로 Git 저장소 작업의 흐름에 어떤 영향을 미칠지 궁금합니다.

주 버전이 v0 또는 v1이면 버전 번호 요소를 생략해야 합니다. 그렇지 않으면 포함되어야 합니다.

현재로서는 마스터에서 작업하고(저에게는 여기에는 단기 기능 분기가 포함됨) 때때로 새 버전으로 커밋에 태그를 지정하는 것이 일반적입니다. 이제 master 및 v2 분기가 있으므로 내 라이브러리의 v2를 릴리스하자마자 이 워크플로가 Go 모듈과 더 혼란스러워지는 것 같습니다. master 는 현재 분기이고 v2 는 유지 관리 분기가 될 것으로 예상하지만 정확히 그 반대입니다.

기본 브랜치가 master 에서 v2 로 변경될 수 있다는 것을 알고 있지만, 이것은 여전히 ​​새로운 주요 버전을 릴리스할 때마다 업데이트해야 하는 작업을 남겨둡니다. 개인적으로 master 및 v1 분기가 있으면 좋겠지만 이것이 제안서에 정확히 맞는지 잘 모르겠습니다.

새로운 주요 릴리스로 인해 고객 이탈이 발생합니다. 새 릴리스를 만들 때마다 Git 리포지토리(기본 분기)에서 하나의 설정을 변경해야 하는 경우 라이브러리 사용자가 새 버전으로 전환하는 것과 비교하면 매우 적은 비용입니다.

이 제안의 측면이 올바른 인센티브를 설정한다고 생각합니다. 상위 작성자가 이전 버전과 호환되는 방식으로 변경을 수행하여 전체 생태계 변동을 줄이는 방법에 대해 생각하도록 권장합니다.

이제 마스터와 v2 브랜치가 있습니다.

대신 마스터에 v2/ 하위 디렉토리를 만들 수 있습니다.

@mrkanister

나는 마스터와 v1 브랜치를 갖고 싶지만 이것이 제안서에 정확히 얼마나 맞는지 잘 모르겠습니다.

https://research.swtch.com/vgo-module 에 대한 내 이해에 따르면 vgo는 버전을 식별하기 위해 분기가 아닌 태그를 사용합니다. 따라서 태그가 올바른 분기를 가리키고 커밋하는 한 마스터에서 개발을 유지하고 v1에서 분기할 수 있습니다.

새로운 주요 릴리스로 인해 고객 이탈이 발생합니다. 새 릴리스를 만들 때마다 Git 리포지토리(기본 분기)에서 하나의 설정을 변경해야 하는 경우 라이브러리 사용자가 새 버전으로 전환하는 것과 비교하면 매우 적은 비용입니다.

이것은 내가 과거에 바둑을 열심히 물어뜯었다고 생각하는 문제적 사고방식이다. 한 프로젝트의 한 사람의 경우 기본 분기를 전환하는 것은 현재 간단합니다. 그렇습니다. 그러나 워크플로 규칙에 어긋난다는 것은 사람들이 특히 여러 언어로 작업할 때 잊어버린다는 것을 의미합니다. 그리고 바둑이 초보자가 배워야 할 완전히 다른 일을 하는 방법에 대한 또 하나의 기발한 예가 될 것입니다. 일반적인 프로그래머 워크플로 규칙에 어긋나는 것은 _전혀 아닌_ 작은 비용입니다.

일반적인 프로그래머 워크플로 규칙에 어긋나는 것은 결코 사소한 비용이 아닙니다.

기존의 방식을 따르지 않는 것이 때때로 혁신의 필수 조건입니다.

제안서의 일부를 올바르게 이해했다면 하위 디렉토리나 새 분기를 만들 필요가 없습니다. go.module을 라이브러리의 올바른 가져오기 경로로 업데이트하기만 하면 잠재적으로 마스터 분기만 가질 수 있고 리포지토리에 0.0, 1.0, 2.0 등으로 태그 를 지정할 수 있습니다.

@mrkanister 제 생각에는 dev의 경우 마스터(또는 모든 dev 분기)를 복제하고 "replace" 지시문(vgo-tour 참조)을 사용하여 가리킵니다. (당신이 의미하는 바를 이해한다면 확실하지 않습니다).

@rsc 로드맵과 우리가 지금 해야 할 일에 대해 좀 더 정확히 알려주셨으면 합니다.
Go 정책을 따르고 3개월(지금 2)에 vgo 기능을 중지합니까?
이제 모든 libs 관리자에게 go.mod 파일을 추가하도록 요청하는 순례자의 지휘봉을 따라가야 합니까, 아니면 제안이 공식적으로 수락될 때까지 기다려야 합니까(이름과 구문이 변경되지 않도록)?

@flibustenet 도구는 1.0 정책의 적용을 받지 않으므로 변경될 수 있습니다.

https://golang.org/doc/go1compat

마지막으로 Go 도구 체인(컴파일러, 링커, 빌드 도구 등)은 현재 개발 중이며 동작이 변경될 수 있습니다. 이는 예를 들어 도구의 위치와 속성에 의존하는 스크립트가 포인트 릴리스에 의해 손상될 수 있음을 의미합니다.

또한 제안에서

제안 승인에 따라 변경될 수 있는 선택적 기능으로 Go 1.11의 모듈 지원을 릴리스할 계획입니다. Go 1.11 릴리스는 사용자에게 "실제" 모듈을 사용하고 중요한 피드백을 제공할 수 있는 기회를 제공합니다. 세부 사항이 변경될 수 있지만 향후 릴리스에서는 Go 1.11 호환 소스 트리를 사용할 수 있습니다. 예를 들어 Go 1.12는 파일 구문이나 파일 이름이 변경된 경우에도 Go 1.11 go.mod 파일 구문을 사용하는 방법을 이해합니다. 이후 릴리스(예: Go 1.12)에서는 모듈 지원이 완료되었음을 선언합니다. 이후 릴리스(예: Go 1.13)에서는 모듈이 아닌 go get에 대한 지원을 종료합니다. GOPATH에서의 작업 지원은 무기한 계속됩니다.

피드백 감사드립니다.

@AlexRouSg

https://research.swtch.com/vgo-module 에 대한 내 이해에 따르면 vgo는 버전을 식별하기 위해 분기가 아닌 태그를 사용합니다. 따라서 태그가 올바른 분기를 가리키고 커밋하는 한 마스터에서 개발을 유지하고 v1에서 분기할 수 있습니다.

당신이 맞습니다. 이것은 이전과 같이 계속 작동할 것입니다.

그걸 제외하고 내가 (그리고 분명히 다른 사람들) 이해하지 못하는 것은 v1 패키지가 존재하지 않도록 하는 이유입니다. 가져오기가 끝날 때 /v1 를 사용하여 가져오기를 시도하고 가져오는 패키지의 go.mod 에도 추가했지만 vgo 는 v1 라는 폴더를 찾습니다. 대신

@mrkanister
가져오기 경로에 v1 또는 v0을 허용하지 않는 주된 이유는 패키지의 호환되는 각 버전에 대해 하나의 가져오기 경로만 있도록 하기 위한 것입니다.
/v1 대신 일반 가져오기 경로를 사용하면 전환이 쉬워지므로 끝에 /v1을 추가하기 위해 모든 가져오기 경로를 업데이트할 필요가 없습니다.

안녕,

제안서의 많은 요점은 환영할만한 것 이상이며 시간이 지남에 따라 등장한 대규모 Go 코드베이스를 길들이는 데 도움이 될 것이지만 "최소 버전 사용" 규칙은 매우 해롭습니다.

• 코드 생태계가 발전하기를 원합니다. 즉, 사람들이 새 버전을 테스트 및 사용하고 문제가 누적되기 전에 조기에 감지하기를 원합니다.
• 보안 문제를 해결하는 새 모듈 릴리스가 가능한 한 빨리 적용되기를 원합니다.
• 가능한 한 빨리 보안 문제를 해결하는 새 모듈 릴리스를 적용할 수 있기를 원합니다. 보안 수정 사항에 항상 태그가 지정되는 것은 아닙니다. 새 릴리스를 피하면 해당 수정 사항도 피할 수 있습니다.
• 새 릴리스에 변경 사항을 조기에 적용하는 보안 수정 사항이 포함되어 있지 않은 경우에도 보안 수정 사항이 포함된 다음 릴리스가 게시될 때 검사할 변경 사항이 적다는 것을 의미합니다. 빨리 하라는 것은 이전에 보지 않은 중간 변경 사항에 휩쓸리는 것입니다.)
• 중간 릴리스를 적용하는 것은 호환성을 깨는 경우에만 해롭고 호환성을 깨서는 안되며, 만약 그들이 그것을 감지하고 모듈 작성자에게 다음 릴리스를 위한 습관을 만들기 전에 알리기 위해 호환성을 깨뜨리면 결국 절대적으로 그렇게 될 것입니다. 필요.
• 여전히 오래된 종속성 버전을 지정하고 매니페스트를 업데이트할 시간을 찾지 못하기 때문에 오래된 코드가 당신을 끌어내리는 것을 원하지 않습니다. 주요 릴리스의 최신 버전을 사용하면 다른 코드 생태계에서 이러한 사회적 요구가 충족됩니다. "더 중요한"(즉, 더 재미있는) 일이 있기 때문에 개발자가 최신 버전을 테스트하고 너무 늦을 때까지 연기하지 않도록 합니다.
  
  
  
  • 이론상으로 모든 코드 조각이 원하는 것을 사용할 수 있도록 무한한 수의 모듈 버전을 제공할 수 있지만 실제로는 동일한 dep를 사용하는 두 개의 모듈을 작성하자마자 버전을 선택해야 하므로 더 복잡한 소프트웨어는 여러 버전을 더 적게 허용합니다. 따라서 곧 전체 호송의 속도를 늦추는 낙오자들을 어떻게 처리해야 하는지에 대한 오래된 문제에 부딪히게 됩니다. 나는 낙오자들에게 "당신 말이 맞아, 당신이 원하는 만큼 천천히 가세요. 모두가 당신을 기다릴 것입니다"라고 말함으로써 이 문제를 관리하는 인간 문화를 만난 적이 없습니다. 착하고 이타적일 수 있지만 생산적이지는 않습니다.
  
  

인간의 관성과 싸우는 것은 힘들고 고통스러운 일이며, 즐겁기 때문이 아니라 발전해야 하기 때문에 싸우는 것입니다. 문제를 피하고 인간이 더 미루도록 부추기는 유쾌한 도구를 만드는 것은 전혀 도움이 되지 않으며 프로젝트 침전과 기술적 부채 축적을 가속화할 뿐입니다. github에는 이미 수십 개의 Go 프로젝트가 있으며, 대부분의 읽어보기는 저자가 중요한 수정을 했기 때문에 사용자에게 업그레이드를 구걸하는 데 전념했으며 가장 오래된 릴리스를 기본값으로 설정하면 문제가 일반화될 것입니다.

좋은 규칙은 "모든 중간 커밋이 아니라 주요 릴리스와 일치하는 최신 릴리스를 사용"하는 것입니다. 그것은 앞으로의 타협과 안정이 될 것입니다. 코드베이스를 가장 잘 알고 사용자를 새 코드 상태로 전환할 때를 현명하게 결정할 수 있는 원래 프로젝트를 명령에 넣습니다.

답이 없는 질문이 메일링 리스트에서 복사되었습니다.

우리는 대부분의 개발자가 서로 다른 주요 버전이 서로 다른 분기에 있는 일반적인 "주요 분기" 규칙을 따르는 것을 선호할 것으로 예상합니다. 이 경우 v2 분기의 루트 디렉토리에는 다음과 같이 v2를 나타내는 go.mod가 있습니다.

vgo에서 지원하는 하위 디렉토리와 이 주요 분기 규칙이 있는 것 같습니다. 내 일화적인 경험에 따르면 Go 또는 다른 언어에서 이 규칙을 따르는 저장소는 없습니다(요즘 상대적으로 사용되지 않는 gopkg.in에 의해 강제된 저장소 외에는 실제로 단일 저장소를 생각할 수 없습니다). 마스터 브랜치는 최신 버전이며 기록에 v2.3.4 태그가 있습니다. 태그는 모든 것을 구분하기 위해 존재합니다(단순한 부 버전이 아님). 이전 버전을 패치해야 하는 경우 마지막 v1 태그에서 분기가 일시적으로 생성되고 커밋이 푸시되고 새 태그가 푸시되고 분기가 요약적으로 삭제됩니다. 버전에 대한 분기가 없으며 현재 마스터/개발/기능 분기 + 버전 태그일 뿐입니다. 나는 Git에서 "모든 것이 ref"라는 것을 알고 있지만 다른 VCS의 경우 구별이 모호하지 않을 수 있습니다.

즉, 위에서 설명한 워크플로를 vgo(v2.0.0, v2.0.1이라는 태그만 있고 분기는 없음)를 사용하여 테스트했으며 작동하는 것 같습니다. 그래서 제 질문은 이것이 지금 작동하지만 의도한 것입니까? 블로그의 다른 두 워크플로만큼 자세히 설명되어 있지 않은 것 같고 v2/v3... 분기 없이 작업하는 것이 위에서 설명한 것처럼 사라지게 될 우발적인 기능이 아님을 확인하고 싶습니다. 누구에게나(특히 Go 커뮤니티 외부에서) 대규모로 채택될 포스트의 워크플로를 설명했습니다.

물론 내 주장은 선호도와 일화에 따라 달라지므로 필요한 경우 모든 언어에서 이를 증명하기 위해 일부 다시 스크랩을 할 의향이 있습니다. 지금까지 제안 게시물이 정말 마음에 들었고 일반적으로 변경 사항에 동의하고 계속해서 vgo를 따라가며 플레이할 것입니다.

모든 노력에 감사드립니다.

누군가 MVS에 대해 제안된 대안 모델이 업그레이드 케이던스를 개선하기 위해 어떻게 작동하는지 명확히 할 수 있습니까? 나에게 명확하지 않기 때문입니다. 대체(널리 사용되는) 모델에 대한 나의 이해는 다음과 같습니다.

• 개발자는 사용된 모든 종속성에 대한 버전 제약을 나열하는 수작업 매니페스트를 생성합니다.
• 개발자는 잠금 파일을 생성하는 $solver를 실행하여 지정된 제약 조건을 충족하는 전이 종속성 버전의 일부 선택된 하위 집합을 나열합니다.
• 이 잠금 파일은 커밋되고 빌드 및 설치 시 재현 가능한 빌드를 보장하는 데 사용됩니다.
• 종속성의 새 버전이 출시되어 사용되는 경우 개발자는 잠재적으로 매니페스트를 업데이트하고 솔버를 다시 실행하고 새 잠금 파일을 다시 커밋합니다.

내가 이해하는 제안된 MVS 모델은

• 개발자는 모듈의 가져오기 경로 세트를 기반으로 go.mod 를 자동 생성하여 전이 종속성의 현재 최신 버전을 선택합니다.
• go.mod 커밋되고 빌드 및 설치 시 버전에 대한 하한값을 얻는 데 사용됩니다. MVS는 재현 가능한 빌드를 보장합니다.
• 새 버전의 종속성이 릴리스되어 사용되면 개발자는 vgo get -u 를 실행하여 최신 버전의 전이 종속성을 가져와 go.mod 를 새 하한으로 덮어씁니다. 그러면 제출됩니다.

뭔가 간과해야 할 것 같고 누군가 지적해 주면 도움이 될 것 같습니다. 이러한 이해는 정확한 버전과 실제 빌드에서 사용되는 버전을 지정하는 잠금 파일로 인해 일반적으로 버전 보류를 허용하지 않기 때문에 MVS가 업그레이드 케이던스를 높이는 데 더 좋습니다 .

분명히 나는 ​​뭔가를 놓치고 있습니다. (약 5m에서 어리 석음이 느껴질 것입니다), 그것은 무엇입니까?

@tpng

/v1 대신 일반 가져오기 경로를 사용하면 전환이 쉬워지므로 끝에 /v1을 추가하기 위해 모든 가져오기 경로를 업데이트할 필요가 없습니다.

이것은 실제로 필요하지 않아야 합니다. 예를 들어보겠습니다.

사용자는 현재 v1.0.0 라이브러리의 종속성 관리자와 업스트림 저장소의 태그에 의해 고정된 라이브러리를 사용하고 있습니다. 이제 업스트림은 go.mod 를 만들고 /v1 모듈도 호출하기로 결정합니다. 그러면 새 커밋과 새 태그가 생성됩니다(예: v1.0.1 ). vgo 는 자체적으로 종속성을 업데이트하려고 시도하지 않으므로 사용자를 위해 아무 것도 손상시키지 않아야 하지만 사용자는 가져오기 경로를 변경하여 의식적으로 업데이트 할 수 있습니다 (pr vgo 가 이를 수행할 수 있음). 그를 위해).

가져오기 경로에 v1 또는 v0을 허용하지 않는 주된 이유는 패키지의 호환되는 각 버전에 대해 하나의 가져오기 경로만 있도록 하기 위한 것입니다.

예, 도서관의 새로운 사용자를 혼동하지 않도록 그 점을 참으로 알 수 있을 것 같습니다.

주 버전이 v0 또는 v1이면 버전 번호 요소를 생략해야 합니다. 그렇지 않으면 포함되어야 합니다.

누군가 이것의 이유를 설명해 주시겠습니까? 라이브러리 사용자로서 v1을 사용하고 싶지 않을 때 의미론적 버전 관리(새로운 주요 버전)에 완전히 문제가 되는 주요 변경 사항이 도입되었기 때문에 어떻게 해야 합니까?

불안정하거나 완료되지 않은 패키지를 나타내는 버전 1 이전 버전만 생략하고 싶습니다. 버전 1부터는 안정적으로 출시된다는 사실에 의지할 수 있었으면 하는 바람입니다. 가져오기 경로에서 v1을 생략하는 것은 혼란스럽습니다. 계속 변경되는 라이브러리를 추적하는지 아니면 안정적인 버전을 추적하는지 알 수 없기 때문입니다. 이것은 v1이 버전 0.x와 해당 버전을 명확하게 구별하는 데 사용되는 첫 번째 안정적인 릴리스를 정확히 지정하는 의미론적 버전 관리 체계와도 잘 작동하지 않는다고 생각합니다.

@kaikuehne

라이브러리 사용자로서 v1을 사용하고 싶지 않을 때 의미론적 버전 관리(새로운 주요 버전)에 완전히 문제가 되는 주요 변경 사항이 도입되었기 때문에 어떻게 해야 합니까?

내가 이해하는 한 vgo 는 패치 버전이 아니라도 자체적으로 종속성을 업데이트하지 않으며 대신 이를 의식적인 결정으로 남겨두십시오. 따라서 라이브러리의 v0.4.5(태그가 있음)에 의존하는 경우 이론적으로 영원히 계속 사용할 수 있습니다. go.mod 파일에 버전을 수동으로 고정할 수도 있습니다.

내가 사용하는 다른 종속성이 동일한 패키지에 의존하지만 버전 v1에 의존한다면 어떻게 됩니까? 두 패키지 모두 동일한 가져오기 경로를 사용하여 가져옵니다. 동일한 바이너리로 컴파일할 때 충돌이 발생하지 않습니까?

v1이 가져오기 경로의 일부이기도 하도록 요구하는 경우 둘 다 서로 다른 패키지로 취급됩니다.

@kaikuehne 그러면 작동하는 최소 공통 버전으로 업데이트됩니다. (내 이해로)

@kaikuehne 나는 당신의 추론을 이해하지 못합니다. 당신은 v0을 사용하고 있으므로 아마도 당신은 주요 변경 사항에 문제가 없을 것입니다. 이미 안정성이 보장되지 않는 버전을 사용하고 있는데 v1이 중단되면 왜 문제가 될까요? 또한 v0.1->v1.0에서 주요 변경 사항으로 이동하는 대신 업스트림에서 v0.2에 중단을 추가 한 다음 (비중단) v1.0을 릴리스합니다. 이는 시맨틱 버전에 대한 기대치 내에서 잘 맞는 것처럼 보이지만 정확히 동일한 양의 수고를 들일 것입니다(사용된 패키지 관리자에 관계없이). 즉, "작성자가 갑자기 API 중단을 중단함"이 1.0 이전 릴리스의 사용으로 인해 발생하지 않은 문제를 구성하는 방법을 정말 이해하지 못합니다.

다시 말해서: v0.x를 사용하면 v0.(x+1)이 강제로 코드를 수정할 수 있다는 사실을 받아들이게 됩니다. v0.(x+1)을 대신 v1.0이라고 하면 왜 문제가 되나요?

토론 포인트 4: 가져오기 호환성 규칙을 명시적으로 채택하고 "새 패키지는 이전 패키지와 하위 호환되어야 함"...

제 경우에는 https://github.com/microcosm-cc/bluemonday 보안 패키지가 있고 최근(작년 말) public func가 기본적으로 목적에 적합하지 않다는 것을 알게 된 시나리오가 있었습니다. 그래서 나는 그것을 제거했다.

이 제안에 따라 기능을 제거하면 버전이 충돌하고 안전하지 않은/안전하지 않은 코드는 절대 제거되지 않습니다.

이를 피하기 위해 순전히 기존 코드가 안전하지 않은 끝점을 사용하지 않고 호환성을 유지하기 위해 제거하려는 func 내에서 log.Fatal()을 대신할 것입니다.

이들 중 어느 것도 이상적이지 않다는 점을 감안할 때... 공개 기능이 강력하게 사용 중지되어야 하는 보안 수정 사항이 처리될 것으로 예상하는 방법은 무엇입니까? (런타임 log.Fatal()로 개발자를 놀라게 하지 않는다면?)

이에 대한 커밋을 보고 싶은 분들을 위해: https://github.com/microcosm-cc/bluemonday/commit/a5d7ef6b249a7c01e66856b585a359970f03502c

@Merovius 버전 0.x를 사용할 때 설명해주셔서 감사합니다. 당신이 말했듯이, 1.0 이전 버전을 사용할 때 의존할 보장이 없으며 버전 0.x는 semver에서 특별한 경우입니다. 내가 올바르게 이해했다면, 요약된 규칙은 실제로 버전 0.x에 전혀 적용되지 않습니다. 내 질문은 특히 패키지 이름을 지정할 때 코드에서도 이러한 구분을 반영하는 것이 타당한지 여부입니다. 예를 들어 패키지가 버전 없이 패키지만 가져온 경우 불안정한 코드를 기반으로 구축되었음을 한눈에 알 수 있습니다. 모든 가져오기에 버전 v1이 포함되어 있으면 안정적인 버전을 사용하는 것을 볼 수 있습니다.

@buro9 제안은 보안 관련 API 파손에 대한 면제를 포함하는 go1 호환성 보장을 대략 따를 것을 제안합니다.

@kaikuehne 감사합니다. 걱정이 명확해졌습니다.

내가 걱정하는 기능의 상호 작용이 있습니다(정확하게 이해한다고 가정).

구체화된 버전(태그에서 파생된 합성 가져오기 경로 요소가 아닌 소스의 리터럴 vN 디렉토리)을 사용하는 모듈 M이 있고 M의 여러 주요 버전에 전이적으로 의존하는 프로그램 P를 빌드하는 경우 그렇지 않습니다. 일부 시나리오에서 최소 버전 선택을 위반해야 합니까?

즉, P가 M의 주요 버전 2, 3 및 4에 의존한다고 가정합니다. M의 각 주요 버전에 대해 지정된 최소 전체 버전이 있습니다. M 버전은 유형 별칭이 있는 동일한 유형 정의를 투명하게 사용하는 것과 같은 작업을 수행할 수 있다는 명시적 목적을 위해 소스를 공유하기 때문에 M의 하나의 사본만 주 버전당 하나의 사본 대신 세 가지 주 버전 모두에 포함될 수 있습니다. 하나의 주 버전에 대한 전체 버전을 선택하면 다른 두 주 버전의 전체 버전에 대한 선택이 수정되고 다른 주 버전 중 하나 또는 둘 모두에 대해 최소가 아닌 버전을 선택할 수 있습니다.

vgo는 이것을 어떻게 처리합니까? 이것이 때때로 최소한의 것보다 약간 적은 것 외에 다른 문제를 일으킬 수 있습니까? (예를 들어 솔루션이 생성되지 않거나 솔버가 루프하도록 하는 모듈 세트를 실수로 구성하는 것이 가능합니까?)

@jimmyfrasche

주요 버전 디렉토리를 사용하는 경우 vgo는 여전히 태그를 사용하고 해당 태그와 일치하는 버전 폴더만 가져옵니다. 예를 들어 버전 2, 3, 4에 의존하고 있습니다. vgo는 v2.nm, v3.nm, v4.nm 태그를 체크아웃합니다.
그런 다음 태그 v2.nm에서 v2 폴더 등만 가져옵니다. 따라서 결국 모든 것이 여전히 태그를 따릅니다.

이 메일링 리스트 게시물 에서 질문을 했지만 구체적인 답변을 보지 못했습니다. 여기서 반복하겠습니다.

protobufs 또는 c 파일과 같은 Go가 아닌 리소스는 어떻게 되나요? 귀하의 게시물에서 이미 답변을 했다면 죄송합니다. 하지만 공급업체 경로를 사용하여 protobuf 파일의 가져오기 경로를 배포하고 설정합니다. 미리 컴파일된 protobuf 출력에 대해 Go 패키지를 컴파일하는 동안 공급업체 종속성에 따라 protobuf 파일에서 새 Go 패키지를 컴파일하는 경우도 고려해야 합니다(즉, 다른 protobuf 파일에서 rpc.Status 참조). 설명이 너무 조밀하다면 더 구체적인 예를 제공할 수 있습니다.

특히 protobuf 파일 가져오기를 GOPATH 위치에 매핑할 수 있는 protobuild 라는 프로젝트가 있습니다. 이 제안이 GOPATH의 리소스 해결을 처리하는 방법과 이를 다른 컴파일러 가져오기 공간에 매핑하는 방법을 알지 못합니다.

이것은 우리에게 protobuf로 작업하는 데 있어 큰 고충이었고 이 프로젝트는 이러한 문제를 많이 완화했습니다. 이것이 제안과 완전히 호환되지 않는다면 부끄러운 일입니다.

제가 놓친 부분이 있다면 다시 한 번 사과드립니다.

나는 그 제안을 좋아한다. 너무 많은 프로젝트에서 부 버전 간에 작은 주요 변경 사항을 자주 도입하고 매우 큰 주요 변경 사항에 대해서만 주요 버전 범프를 예약하는 것이 걱정됩니다. 마이너 버전 변경이 자주 발생하면 SIV의 가정을 위반하므로 다이아몬드 종속성 문제가 발생합니다. import 문에 부 버전을 포함하면 더 많은 프로젝트가 비핵화 변경 계약을 준수하는 데 도움이 될지 궁금합니다. 단점은 추가 가져오기 변동이고 부 버전을 업데이트하는 것이 더 어려워지고 더 명확해진다는 것입니다.

이것은 내가 가진 또 다른 질문을 제기합니다. vgo를 사용하여 빌드에 1개 이상의 패키지 버전이 있는지 확인하는 것이 (오늘날) 쉬운가요? 동일한 패키지의 두 가지 버전을 허용하는 것이 때때로 앞으로 나아가는 데 중요하지만, init의 예상하지 못한 부작용으로 인해 일시적인 경우가 아니면 대부분의 프로젝트에서 이것을 피하고 싶어하는 것 같습니다. 이를 쉽게 확인할 수 있는 방법이 있으면 유용할 수 있으며 일부 프로젝트에서는 코드 체크인 중에 이를 적용하기를 원할 수 있습니다.

너무 많은 프로젝트에서 부 버전 간에 작은 주요 변경 사항을 자주 도입하고 매우 큰 주요 변경 사항에 대해서만 주요 버전 범프를 예약하는 것이 걱정됩니다.

브레이킹 체인지는 브레이킹 체인지입니다. 작거나 클 수 없습니다. 나는 그러한 패키지가 결국 커뮤니티에서 너무 신뢰할 수 없고 semver를 따르지 않는다고 거부할 것이라고 생각합니다. semver를 따르고 42.xx와 같은 큰 주요 번호에 빠르게 도달하더라도 어쨌든 사용하기가 매우 불편할 것입니다. 따라서 많은 주요 변경 사항을 적용하려면 주요 번호 0을 계속 사용하십시오. 이렇게 하면 현재 go get 처럼 동일한 문제로 계속 작동합니다. 0이 아닌 주요 버전을 출시한 후 API를 실험하려면 이 실험을 영구 주요 0이 있는 "실험적" 패키지를 분리하고 "작은 주요 변경 사항"을 완료하면 기본 패키지의 주요를 증가시키고 마침내 다음 안정적인 API를 얻으십시오.

import 경로에 minor를 포함하는 것은 semver 이념을 위반하고 Major를 포함하는 것 이상의 새로운 기능을 제공하지 않습니다.

그것이 작성자가 semver의 의미를 감안할 때 수행 해야 하는 일이라는 것을 이해하지만, 마이너 버전 간의 사소한 주요 변경 사항은 이미 버전 1을 지난 사람에게 일반적이고 유혹적인 경우입니다. 내 일화적 경험에 따르면 패키지 작성자는 semver의 정확한 의미를 따르고 종종 회사는 마케팅 목적으로 주요 버전 범프를 예약합니다. 그래서 나의 호소는 무엇이 이상적이냐가 아니라 semver라는 지저분한 인간 현실을 더 잘 다루기 위해 특정한 변화를 만드는 것이 실용적일 수 있는지에 관한 것입니다.

semver를 따르지 않는 패키지에 대한 마이너 버전을 선택적으로 포함하는 것이 가능할 수도 있습니다. 어쩌면 전체 제안을 망칠 수도 있습니다. 더 깊이 생각해야 합니다. 이것이 더 나은 방법이라고 제안하는 것이 아니라 수입에 부 버전을 선택적으로 포함하거나 포함하도록 의무화하는 것의 장단점을 추가로 탐구하는 데 관심이 있습니다.

semver 태그를 사용하는 기존의 인기 있는 프로젝트에서 semver가 가장 많이 사용되는 빈도를 결정하기 위해 go corpus(및 명백한 주요 변경 사항을 찾는 도구)에서 더 나은 데이터를 생성할 수 있습니다.

vgo 제안을 통해 주요 버전은 API 변경 사항을 정상적으로 중단할 수 있습니다. 그것은 (자체적으로) 그들을 방지하기 위해 아무 것도 하지 않습니다.

vgo 제안 은 하나의 주 버전이 다른 주 버전을 참조하도록 허용하여 우아한 코드 재사용을 허용합니다. 그것을 강제하는 것은 아무 것도 하지 않습니다.

vgo MVS 제안을 통해 최신 패키지로 업데이트할 수 있습니다. 업데이트를 강요하지 않습니다.

vgo 세계에서 훨씬 쉽게 구축할 수 있는 사항은 다음과 같습니다.

1. 모듈 호스트로 푸시하기 전에 API 제동 변경 사항을 포착하는 도구입니다. 각 버전은 압축되어 있으며 다양한 vcs 도구 및 명령 없이 비교할 수 있습니다.
2. 보안 문제 레지스트리. 부가가치를 위해 호스트하는 모듈 옆에 있는 호스트. 도구는 go list 와 유사하게 수동 또는 자동으로 쿼리하고 쿼리로 필터링된 문제에 대한 알림을 받을 수 있습니다.

vgo를 사용하면 다음과 같이 더 쉽게 작업할 수 있습니다.

• 문제 공간 제한(zip 파일에서만 작동, API 비교를 위해 임의의 git/hg/svn 기록을 저장할 필요 없음).
  
  
  
  • 문제 공간 정의(MVS, 버전 정의)
  
  
• 빌드 부분 툴링.

vgo는 하나의 주요 원칙에 따라 작동합니다. 단일 입력 세트는 항상 동일한 것을 빌드해야 합니다. 보안 업데이트를 잡기 위해 무작위 재구축에 의존한다면 우리는 잘못하고 있는 것 입니다. 프로젝트의 유지 관리자로서 일부 Go 프로젝트는 다시 빌드하지 않고 몇 년 동안 실행됩니다. 시기 적절한 보안 업데이트가 중요하다는 데 동의합니다. vgo는 이러한 요구 사항의 빌드 부분을 충족합니다.

vgo가 허용하는 것과 vgo가 무엇인지를 혼동해서는 안 됩니다.

@pbx0 여기 가 그러한 토론에 적합한 장소인지 확실하지 않습니다. 아마도 maillist가 더 적합할 것입니다. 어쨌든 메이저 번호를 변경하지 않고 주요 변경 사항이 발생합니다. 가끔이라도. Semver는 FAQ에서 이 사례에 대한 답변을 받았습니다.

시맨틱 버전 지정 사양을 위반했다는 것을 깨닫는 즉시 문제를 수정하고 문제를 수정하고 이전 버전과의 호환성을 복원하는 새 부 버전을 릴리스하십시오.

하지만 여기에는 개선의 여지가 있다고 생각합니다. godoc.org에 나열된 모든 패키지를 가져와 주기적으로 새 버전을 확인하고 새 버전이 감지된 경우 확인이 이전 버전과 호환되는 새 버전인지 확인하는 자동화된 API 검사기(이미 존재할 수도 있음)를 구현하는 것이 충분히 쉬워야 한다고 생각합니다. semver 태그를 사용하고 Major가 변경되지 않은 경우 버전의 API입니다. 그런 다음 호환되지 않는 변경 사항이 감지된 경우 작성자에게 문의하십시오. github에서 자동 열기 문제 또는 github 계정의 이메일을 사용할 수 있습니다. 가능한 모든 경우를 다루지는 않겠지만 커뮤니티에 매우 도움이 될 수 있습니다.

저는 주요 버전의 범위를 지정하기 위해 경로를 사용하는 것을 굳게 믿으며 FWIW를 지원하고 싶었습니다.

1년 전, 저는 이와 같은 가져오기 경로에 버전을 넣는 것이 보기 흉하고 바람직하지 않으며 아마도 피할 수 있다고 믿었습니다. 그러나 지난 1년 동안 나는 그것들이 시스템에 얼마나 명료성과 단순성을 가져다 주는지 이해하게 되었습니다.

거의 20년 전 저는 스타트업에 VCS가 필요했고 약 10가지 다른 것을 시도했습니다. 나는 디렉토리를 사용하여 분기를 노출했기 때문에 Perforce를 즉시 배제했습니다. 따라서 v2 분기는 모두 동일한 코드이지만 v2 폴더 아래에 있습니다. 나는 이 생각이 싫었다. 그러나 다른 9개와 함께 파일럿을 실행한 후 로컬 파일 시스템에 두 가지 버전의 분기를 모두 갖고 싶어하는 경우가 많았고 Perforce는 이를 사소하게 만드는 반면 나머지는 놀라울 정도로 복잡하게 만들었습니다. 파일 시스템은 우리의 격리 은유입니다. 사용합시다.

제안서에서:

사용자 정의 도메인 이름을 사용하여 모듈을 설치하고 $GOPROXY 환경 변수가 설정된 경우에도 사용되는 프록시에서 Go 모듈을 가져오기 위한 URL 스키마를 정의하십시오. 후자를 사용하면 회사와 개인이 보안, 가용성 또는 기타 이유로 프록시를 통해 모든 모듈 다운로드 요청을 보낼 수 있습니다.

나는 이것을 다른 곳에서 언급했지만 이 제안에 대한 나의 가장 큰 우려는 이것이 오늘날 벤더링의 가장 큰 장점 중 하나인 항상 사용 가능한 코드와 완벽하게 재현 가능한 빌드를 폐기하는 것(또는 최소한 해결하지 않는 것)이라는 것입니다. 나는 제안된 프록시 시스템이 이러한 강점을 적절하게 다루거나 대체한다고 생각하지 않습니다.

오늘날 벤더링을 사용하는 프로젝트에는 Go 도구 체인과 Git(또는 다른 버전 제어 시스템)만 필요합니다. 단일 실패 지점은 git 저장소뿐입니다. 코드가 체크아웃되면 네트워크를 다시 건드릴 필요 없이 완벽하게 구축 및 재구축할 수 있습니다. 이는 중요한 보안 고려 사항입니다. 우리 대부분에게 벤더링 프로젝트에는 추가 인프라가 필요하지 않습니다. 로컬 컴퓨터와 무료 GitHub 계정만 있으면 됩니다.

vgo 의 프록시에 대한 의존도는 충분히 강조되지 않았다고 생각되는 사소하지 않은 인프라 오버헤드를 도입합니다. 새로운 인프라를 프로비저닝, 구현, 유지 관리 및 모니터링해야 합니다. 이는 소프트웨어 조직에게는 합리적일 수 있지만 개인 및 분산형 오픈 소스 프로젝트에는 부담이 됩니다. 또한 CI와 같은 것은 회사의 개발 환경과 동일한 인프라에서 실행되지 않는 Travis CI와 같은 타사에 아웃소싱되는 경우가 많습니다. 이로 인해 프록시 인프라를 재사용하기가 더 어려워집니다.

다른 언어에서는 캐싱 프록시를 사용할 수 있습니다. Python은 내가 가장 많이 경험한 것이고, 내 경험상 Python을 설정하는 오버헤드 때문에 거의 사용되지 않습니다. Go 프로젝트는 이것을 더 간단하게 만들 수 있지만 기본값이 아닌 경우 덜 자주 사용되며 야생에서 Go 빌드의 가용성이 크게 감소합니다. 왼쪽 패드 NPM 이벤트의 영향은 이와 관련하여 훌륭한 사례 연구입니다.

모듈 및 프록시 시스템을 통해 우리 자신의 프로젝트 코드(오늘날 공급과 유사하지만 반드시 동일한 구현은 아님)와 함께 종속성을 확인할 수 있고 vgo 프록시 구현이 이를 사용할 수 있다면 내 문제를 해결할 수 있습니다. 그러나 그것이 의도라면 제안서에서 훨씬 더 충분히 다루어야 한다고 생각합니다.

@joeshaw 계속해서 공급업체 디렉토리를 사용하여 자체 포함된 빌드를 만들 수 있습니다.

제안서에서:

한 가지 제한된 사용을 제외하고 공급업체 디렉토리의 사용을 허용하지 않습니다. 빌드 중인 최상위 모듈의 파일 트리 맨 위에 있는 공급업체 디렉토리는 계속해서 자체 포함된 애플리케이션 저장소를 허용하기 위해 빌드에 적용됩니다. (다른 공급업체 디렉토리를 무시하면 Go가 빌드 전체에서 각 가져오기 경로가 동일한 의미를 갖는 빌드로 돌아가고 지정된 가져오기 경로가 있는 패키지 사본 하나만 지정된 빌드에서 사용되도록 설정합니다.)

오늘날 벤더링을 사용하는 프로젝트에는 Go 도구 체인과 Git(또는 다른 버전 제어 시스템)만 필요합니다. 단일 실패 지점은 git 저장소뿐입니다.

오늘날 자신의 도메인에서 패키지를 호스팅하는 경우 a) git-repository를 호스팅하고 b) go-get이 패키지를 찾는 데 필요한 <meta> 태그를 제공해야 합니다. 앞으로는 a) vgo가 코드를 가져오는 데 필요한 .zip 및 .json 파일을 제공해야 합니다. 순수한 호스팅에 필요한 장애 지점과 인프라가 더 적은 것 같습니다. 물론 여전히 개발을 위해 리포지토리를 호스팅해야 하지만, 그렇게 하면 최악의 경우 이전과 같은 수준이 될 뿐만 아니라 리포지토리 자체도 실제로 개발 중인 사람들만 사용하기 때문에 확장성과 안정성이 훨씬 떨어지는 호스팅이 필요합니다.

따라서 베니티 수입의 경우 간접비 측면에서 큰 차이가 없어 보입니다.

OTOH, 베니티 가져오기를 사용 하지 않는 경우 github 에서 실행 중인 모든 인프라를 무시하는 것입니다. 따라서 이것은 사과 대 사과 비교가 아닌 것 같습니다. 당신이 정상에 오를 수 있는 유일한 방법은 다른 사람들이 어려운 문제를 해결하도록 하기 때문입니다. 그러나 앞으로 그렇게 하는 것을 방해하는 것은 없습니다. AIUI Microsoft 및 기타 업체는 이미 이 작업에 엔지니어링 시간과 서비스 용량을 투자하기로 자원했습니다. 나는 미래에 Go 패키지를 호스팅하는 노력이 npm 패키지, gem 또는 crates를 호스팅하는 노력에 의해 거의 제한되지 않을 것이라고 예상합니다. zip을 호스팅하는 관리 서비스.

vgo 의 프록시 의존도

개인적으로 필요한 인프라가 수행하는 작업에 대해 "프록시"라는 단어를 좋아하지 않습니다. "거울"이 더 적절해 보입니다. 미러 는 프록시로 구현될 수 있지만 거의 무한한 확장성과 가동 시간을 위해 Cloudflare 뒤에 숨겨진 선택한 웹 서버에서 제공하는 파일 묶음일 수도 있습니다.

다른 언어에서는 캐싱 프록시를 사용할 수 있습니다.

나는 다른 언어가 이것이 실제로 문제가 되지 않는 이유에 대한 완벽하게 훌륭한 모델 역할을 한다고 주장합니다. 그들은 패키지를 호스팅하기 위해 패키지에 대한 중앙 집중식 호스팅에 의존하는 경향이 있습니다 vgo 는 이 모델을 매우 잘 지원할 뿐만 아니라 선택 사항으로 만듭니다(따라서 단점 없이 모든 이점을 얻을 수 있음) 및 매우 간단합니다. 구현, 확장 및 운영합니다.

IMO, Go와 다른 언어에서 일어나는 일과 전후에 일어나는 일을 직접 비교하면 1:1 등가물이 많다는 것이 분명할 것입니다. 그리고 앞으로 더 많은 노력이 필요할 것 같은 유일한 이유는 기존 인프라를 당연하게 여기고 새로운 인프라가 아직 존재하지 않는다는 것을 알기 때문입니다. 하지만 그럴 것이라고 의심할 충분한 이유가 없다고 생각합니다.

따라서 베니티 수입의 경우 간접비 측면에서 큰 차이가 없어 보입니다.

사실이지만 _광대한_ 소수의 패키지가 베니티 도메인을 사용하므로 이것이 강력한 반대 의견이 아니라고 생각합니다. (저는 또한 허영 도메인에 대한 다른 실제적인 문제가 있습니다. 바로 GitHub를 사용하는 것보다 가용성이 _훨씬 더 나빠지는 경향이 있다는 것입니다.)

OTOH, 베니티 가져오기를 사용하지 않는 경우 github에서 실행 중인 모든 인프라를 무시하는 것입니다.

예, 정확히! 이것이 제 요점이라고 생각합니다. 인프라에 대한 모든 멋진 작업과 가동 시간 유지 관리를 무료 또는 합리적인 비용으로 얻을 수 있습니다. 더 중요한 것은 귀하의 시간이 포함되지 않는다는 것입니다.

GitHub가 vgo -호환 미러를 실행하게 된다면 아마도 이것은 문제가 되지 않을 것입니다. 하지만 저는 모든 코드를 포함하는 단일 Git 가져오기(사용자의 관점에서 원자적 동작)를 좋아합니다. 프로젝트를 빌드해야 합니다.

나는 다른 언어가 이것이 실제로 문제가 되지 않는 이유에 대한 완벽하게 훌륭한 모델 역할을 한다고 주장합니다. 그들은 패키지를 호스팅하기 위해 패키지에 대한 중앙 집중식 호스팅에 의존하는 경향이 있습니다. vgo는 이 모델을 매우 잘 지원할 뿐만 아니라 선택 사항으로 만듭니다(따라서 단점 없이 모든 이점을 얻을 수 있음). 구현, 확장 및 작동하다.

문제는 이것이 프로젝트 구축에 단일 실패 지점(SPOF)을 추가한다는 것입니다. 코드는 무엇이든(그리고 아마도 GitHub) VCS에 있을 것이므로 하나의 SPOF입니다. 다른 언어에서 중앙 저장소는 두 번째 SPOF입니다. Go의 경우 모든 가져오기 경로는 추가 SPOF(github.com, golang.org, honnef.co, rsc.io 등)이며 SPOF를 늘리면 전체 가용성이 낮아집니다.

미러를 실행하면 물론 다시 2로 줄일 수 있지만 존재할 필요가 없다고 주장하는 인프라입니다. dep를 판매하거나 로컬 디스크 미러를 사용하면 이것을 VCS로 다시 줄일 수 있습니다.

어쨌든 이것은 논쟁의 여지가 있습니다. 나는 원래 내 주요 관심사를 해결하는 것처럼 보이는 최상위 vendor 디렉토리에 대한 제안의 일부를 이해하지 못했습니다. @kardianos 를 지적해 주셔서 감사합니다. 판매 시스템이 더 좋을 수 있습니다.

git grep 를 너무 사랑하기 때문에 "최상위 vendor "가 여전히 지원되는 구성이 될 수 있어 기쁩니다.

미러를 실행하면 물론 다시 2로 줄일 수 있지만 존재할 필요가 없다고 주장하는 인프라입니다.

여기 엔터프라이즈 개발자입니다. 어쩌면 우리는 타겟 인구 통계가 아니지만 Go를 사용하고 싶습니다. 우리가 오늘 구축한 모든 것이 내일 구축될 수 있도록 자바와 자바스크립트에서 하는 것처럼 기업 내부에 미러 없이는 그런 일이 일어나지 않는다는 것을 알 수 있습니다.

여기 엔터프라이즈 개발자입니다. 어쩌면 우리는 타겟 인구 통계가 아니지만 Go를 사용하고 싶습니다. 우리가 오늘 구축한 모든 것이 내일 구축될 수 있도록 자바와 자바스크립트에서 하는 것처럼 기업 내부에 미러 없이는 그런 일이 일어나지 않는다는 것을 알 수 있습니다.

@jamiethermo 오늘 벤더링에서 해결하지 않습니까?

프록시나 미러에 대한 지원은 괜찮고, 그것이 Go 채택에 도움이 된다면 저는 전적으로 찬성합니다. 내 관심사는 로컬 독립 소스 트리(오늘날 벤더링이라고 함)를 대체하는 미러였습니다.

@joeshaw

오늘날 벤더링에서 이 문제를 해결하지 않습니까?

글쎄, 나는 무지와 "내 코드를 어떻게 구성해야 하는가"에 대한 어느 정도의 좌절을 고백해야 합니다. "자체 포함된 소스 트리"란 모든 코드와 공급업체 트리의 모든 코드를 포함하는 거대한 git repo가 ​​있다는 것을 의미합니까? 다른 모든 코드를 내 저장소에 체크인했기 때문에 미러가 필요하지 않습니까?

"내 코드를 구성하는 방법"과 관련하여 이 페이지, Go 코드 작성 방법 은 디렉토리 구조에 대해 설명하지만 공급업체에 대해서는 언급하지 않습니다.

각 주요 버전에 고유한 가져오기 경로가 있는 의미 체계 가져오기 버전 관리를 채택합니다. 특히, 가져오기 경로에는 모듈 경로, 버전 번호 및 모듈 내부의 특정 패키지에 대한 경로가 포함됩니다. 주 버전이 v0 또는 v1 이면 버전 번호 요소를 생략해야 합니다. 그렇지 않으면 포함되어야 합니다.

my/thing/sub/pkg , my/thing/v2/sub/pkg 및 my/thing/v3/sub/pkg 로 가져온 패키지는 my/thing 모듈의 주요 버전 v1 , v2 및 v3에서 가져옵니다. 빌드는 그것들을 단순히 세 개의 다른 패키지로 취급합니다.

my/thing/sub/pkg도 v0이 될 수 있습니다.

나는 여행 을 따랐다. 이 예제는 GOPATH 트리 외부에 빌드되어 작동하지만 해당 상황에서는 dep init barfs입니다. 저는 지금 80개 팀과 함께 일하고 있으며, 거대한 나무가 하나 없어도 정말 좋을 것 같습니다. (내가 이것을 타이핑하고 있을 때 누군가가 노트북과 찡그린 얼굴로 다가와 "이거 정말 이상한 버그가 있어...")

@joeshaw

인프라에 대한 모든 멋진 작업과 가동 시간 유지 관리를 무료 또는 합리적인 비용으로 얻을 수 있습니다.

나는 그것을 나쁘게 표현했다. "베니티 가져오기를 사용하지 않는 경우 더 적은 인프라가 필요하다고 주장한다면 github이 실행하는 모든 인프라를 무시하는 것입니다"라고 말하고 싶었습니다. 인프라가 여전히 존재하고 여전히 실행해야 한다는 점을 지적하고 싶었습니다. 그리고 앞으로도 계속해서 실행할 수 있습니다.

따라서 귀하의 우려는 내가 가장 가능성 있는 시나리오라고 생각하는 것에서 해결될 것입니다. 자금 지원 기관(현재 Microsoft는 그렇게 하기 위해 준비 중임)이 zip 파일 호스팅을 수행하고 있습니다.

단일 Git 가져오기의 우아함을 좋아하지만 사용자 관점에서 원자적 동작

vgo get 는 원자적 동작과 동일하며 더 적은 작업을 수행하며 동일한 특성(HTTP 요청)을 더 쉽게 이해할 수 있습니다.

문제는 이것이 프로젝트 구축에 단일 실패 지점(SPOF)을 추가한다는 것입니다.

그렇다면 내 마지막 댓글이 잘못된 곳은 어디입니까? 내가 보기에 실패 지점의 수가 적 다면 더 간단하고 확장하기 쉽고 실행 비용이 저렴합니다.

다른 언어에서 중앙 저장소는 두 번째 SPOF입니다. Go의 경우 모든 가져오기 경로는 추가 SPOF(github.com, golang.org, honnef.co, rsc.io 등)이며 SPOF를 늘리면 전체 가용성이 낮아집니다.

나는 이것이 지나치게 단순화되었다고 생각합니다. 다운되는 미러에서 코드를 호스팅하는 경우 계속 개발할 수 있고(github가 여전히 작동 중임) 사용자는 여전히 설치할 수 있습니다(다른 미러를 사용하여). 종속성 중 하나가 다운되는 호스트는 종속성을 미러링하므로 중요하지 않습니다. "중앙 집중식" 커뮤니티 운영 미러를 신뢰할 수 없다면 직접 운영하거나 다른 사람에게 비용을 지불하여 수행할 수 있습니다. 중앙 집중식 리포지토리.

당신이 언급한 것 중 어느 것도 실제로 SPOF가 아닙니다. 여전히 최소한 성능이 저하된 작업을 얻을 수 있기 때문입니다. 게다가 실제 미러는 작동하기가 비교적 간단하고(그냥 상태가 없는 HTTP 서버이기 때문에) 안정성과 가용성이 의미 있게 감소할 것이라는 확신이 없습니다.

그리고 FTR, 현재 git-hosting 은 SPOF입니다. git-host가 다운되면 사용자가 설치할 수 없고 개발할 수 없습니다.

미러를 실행하면 물론 다시 2로 줄일 수 있지만 존재할 필요가 없다고 주장하는 인프라입니다.

그리고 위의 (잘못 표현된) 요점은 이미 그렇게 하고 있다는 것입니다 :) 당신은 단순히 a) 바로 지금 발생한다는 것을 무시하고 b) 미래에는 일어나지 않을 것이라고 가정합니다 :)

다른 관점을 제공하려면:

• 우리는 시스템 전체의 교차 언어 소프트웨어 구성 요소 관리자(Fedora, Centos 및 RHEL의 rpm/dnf)를 사용하여 많은 Go 프로젝트를 구축하고 있습니다.
• rpm 계층 구성 요소 네임스페이스에서 재생하여 vgo 제안과 동일한 트릭을 많이 사용할 수 있습니다(일반적으로 rpm 네임스페이스 수준에서 프로젝트의 이름을 프로젝트에서 compat-project-x로 변경하여 vgo가 수행하는 것과 동일한 가져오기 경로).
• 이 트릭은 복잡한 Go 프로젝트 빌드를 돕는 데 확실히 유용합니다.
• 언어 수준에서 수행하는 것만큼 완전하고 강력하지는 않지만
• 원래 코드에 제약 조건의 rpm/dnf 오버레이를 추가하는 것보다 rpm/dnf에 언어 제약 조건을 릴레이하는 것이 좋습니다.
• 우리는 현재 Go 도구가 Go 프로젝트 소스를 보도록 설득하는 데 필요한 모든 파일 시스템 해결 방법이 지겹습니다. 물리적 GOPATH는 전혀 놓치지 않을 것입니다.

따라서 우리는 vgo에 대해 흥분하고 곧 배포되기를 희망합니다(몇 년 전에 필요했습니다).

즉, vgo와 같은 워크플로를 사용하면 다음과 같은 어려움이 나타납니다.

vgo 제안은 makefile을 불필요하게 만든 것을 축하합니다. 이것은 사실이 아닙니다.

• 많은 Go 프로젝트가 자동 생성된 go 파일과 사랑에 빠졌고 이를 재생성하거나 세대가 성공하는 데 필요한 것을 표현하기 위해 요구하는 표준 방법이 없습니다.
• 많은 프로젝트가 미리 생성된 파일과 함께 제공되어야 하는 것은 너무 나쁩니다(때로는 완전한 별도의 미리 생성된 파일 리포지토리를 구성함)
• 이러한 파일은 버전 비호환성의 큰 원인입니다. 인간은 새로운 종속성 버전에 노출되었을 때 매일 변경할 필요가 없는 코드를 작성하는 데 주의를 기울입니다. 자동 생성 파일 OTOH는 종종 정확한 생성 환경과 밀접하게 연결됩니다. 생성 도구 작성자는 필요에 따라 파일을 다시 생성할 것이라고 가정하기 때문입니다.
• vgo가 성공하려면 해당 파일을 식별하고 .zip 모듈에서 제거하고 .zip 모듈 사용자에게 파일을 재생성하는 방법을 표현하는 방법이 필요합니다.

이것은 현재의 "모든 것이 GOPATH에 있어야 함" 규칙에 의해 악화됩니다.

• 생성이 다국어 프로젝트에 의해 GOPATH 외부에 게시된 프로토 파일에 의존하는 경우 모든 것이 GOPATH에 있을 수 없습니다.
• Go 도구 체인은 GOPATH 외부의 리소스를 읽는 방법을 배워야 합니다.
• Go 도구 체인은 반드시 Go로 작성되지 않은 프로젝트에 노출될 때 GOPATH 외부에 리소스를 게시하는 방법을 배워야 합니다.
• GOPATH를 사용하여 복사본에서 리소스를 복제하는 현재 해결 방법은 버전 비호환성의 또 다른 원인입니다.
• 모든 사람이 동시에 같은 파일을 복사하지 않습니다.
• 때때로 프로젝트는 여러 소스에서 복사하여 독특한 믹스를 만듭니다.
• 모든 프로젝트는 자체 복사본에 대해 QA를 수행하므로 Go 프로젝트 구성이 위험합니다.
• vgo 버전 솔버는 코드 릴리스 간의 관계를 계산하지만 리소스 릴리스 간의 관계를 무시하는 경우 의도한 대로 작동하지 않습니다.
• vgo는 호환되지 않는 모듈 버전의 폭발을 피하기 위해 GOPATH 외부에 게시되는 항목의 개인 복사본을 불필요하게 만들어야 합니다.

많은 프로젝트에서 "모든 Go 디렉터리는 별도의 패키지" 규칙을 악용하여 별도의 하위 디렉터리에 호환되지 않거나 완전히 손상된 코드가 있는 프로젝트를 게시합니다.

• 다른 많은 Go 프로젝트는 동일한 규칙을 사용하여 특정 하위 디렉터리를 선택하고 원래 프로젝트 단위 테스트 및 QA와 호환되지 않는 컨텍스트에서 사용합니다.
• 원래 프로젝트 또는 프로젝트 소비자가 원래 프로젝트의 다른 부분을 사용하지 않는 한 "작동"하고 "재현 가능한 빌드"를 생성합니다. 그렇게 되면 쌓인 기술부채로 모래성 전체가 무너지고,
• 다른 프로젝트의 이전 오용을 정리해야 하기 때문에 최신 프로젝트 버전으로의 업데이트를 거부하는 프로젝트를 볼 수 있습니다.
• 당신은 Go 프로젝트가 그들이 재사용하는 코드베이스의 버그에 대해 책임이 없다고 생각하는 이상한 정신분열증이 있습니다. 동시에 바로 그 동일한 코드베이스에 의해 게시된 수정 사항을 적용하기를 거부합니다(내 생각에 우리는 모두 인간이고 불쾌한 현실 부정은 기본적으로 고정되어 있습니다. 인간의 뇌에서)
• 수정 사항은 전파되지 않으며 처음에 수정 사항이 필요한 버그나 체리 피킹으로 무효화된 단위 테스트에 도달할 때까지는 모든 것이 "정상"입니다.
• 프로젝트의 보안 상태를 공급업체 디렉토리 내부의 동일한 프로젝트의 보안 상태와 비교하는 자동화된 보안 검사기에는 필드 데이가 있습니다.
• 프로젝트가 클수록 공급업체 내부에 이러한 똑딱거리는 폭탄이 숨겨져 있을 가능성이 높아집니다.
• zip 모듈 내에서 프로젝트 경계를 명확하게 정의함으로써 vgo는 이러한 관행을 끝낼 것입니다.
• 그러나 많은 Go 코드베이스를 대대적으로 정리해야 합니다.
• vgo가 성공하려면 기존 Go 프로젝트가 소프트웨어 호환성 관점에서 이해할 수 있는 모듈로 코드베이스를 리팩터링하고 분할하는 데 도움이 되는 도구를 제공해야 합니다. 그렇지 않으면 vgo를 사용하는 프로젝트는 조정 불가능한 제약 조건을 생성하거나 현상 유지를 잠그게 됩니다(기존 코드에서는 작동하지만 코드 진화 관점에서는 끔찍합니다).

프로젝트 간 제한이 거의 없는 단일 GOPATH 트리에서 전체 Go 코드베이스를 노출하는 현재 관행은 소프트웨어 엔지니어링 POW에서 유해한 부작용을 생성했습니다.

• 코드는 기술적 의미가 있는 프로젝트에서 커밋되지 않지만 코드 작성자에게 가장 편리한 저장소(그가 액세스할 수 있는 저장소)에서 커밋됩니다.
• Go 프로젝트는 다른 프로젝트의 일부에 따라 한 프로젝트의 일부가 다른 프로젝트의 일부에 종속되고 이 다른 프로젝트의 일부는 원래 프로젝트에 따라 서로 블리드 아웃됩니다.
• 다른 모든 부분을 이동하지 않고는 한 부분을 이동할 수 없는 잠긴 버전 제약 그래프를 효과적으로 생성합니다.
• 아무도 한 번의 작업으로 다른 모든 것을 변경할 수 있는 리소스를 가지고 있지 않습니다.
• 프로젝트 교착 상태 및 진행 중지
• 명확한 경계가 있는 모듈을 사용하고 모듈 간 버전 제한을 명시적으로 만들려고 하면 이러한 상황이 노출됩니다.
• 그것은 엄청나게 인기가 없을 것입니다 (오늘날 문제가 존재하지만 벤더의 베일 아래 숨겨져 있음)
• 종종 하위 디렉토리를 분리하는 문제가 아닙니다. 문제의 프로젝트 종속성은 A 및 D 수준의 A/B/C/D 디렉토리 트리에서 발생할 수 있지만 B 및 C에서는 발생하지 않습니다.
• vgo가 성공하려면 기존 Go 프로젝트가 종속성 그래프 라인을 따르는 별도의 모듈에서 코드베이스를 리팩터링하고 분할하는 데 도움이 되는 도구를 제공해야 합니다.

Testfing/fixtures, example 및 testdata는 자체 종속성 및 종속성 버전 요구 사항이 있는 완전히 다른 웜 캔입니다.

• 별도의 모듈에서 어떤 식으로든 격리되어야 하며 그렇지 않으면 해당 요구 사항이 솔버 버전 확인에 영향을 미칩니다.
• 그들의 요구를 무시하면 효과적으로 아무도 결정하지 않지만 원래 프로젝트는 단위 테스트를 실행할 것입니다.
• 이것은 버전 업그레이드를 허용할 때 매우 위험합니다. 문제가 발생합니다. 당신은 그들을 감지해야합니다
• 일부 다른 코드뿐만 아니라 원래 프로젝트 외에 누구도 복제할 수 없는 특정 환경(예: 대화할 특정 서버 또는 웹사이트)에 의존하는 통합 테스트, 아마도 특정 격리가 필요할 것입니다.

나는 아마도 더 많은 것을 잊었을 것입니다. 그러나 그것들이 가장 중요합니다.

마지막으로:

• Go 프로젝트는 고립되어 살지 않습니다.
• 일부 Go 프로젝트는 다른 언어로 커넥터를 게시합니다.
• 다른 언어의 일부 프로젝트는 Go 커넥터를 게시합니다.
• 이는 semver를 다른 언어와 다른 방식으로 처리하는 것을 문제로 만듭니다.
• 다국어 프로젝트가 릴리스될 때 Go 부분을 최신 부 버전으로 업데이트하는 것 외에는 모든 것을 가질 수는 없습니다.
• 그것은 운영 관리 POW에서 지옥이 될 것입니다.
• 최신 하위 릴리스로의 자동 업그레이드는 모든 사람이 이전 버전을 진공 상태로 만들어 소프트웨어 제약 그래프를 단순화하는 데 큰 역할을 합니다(이점은 기술적이고 메커니즘은 사회적임).
• 고화질 재구축은 완벽한 픽셀 웹사이트와 유사합니다. 그것들은 분명히 좋은 아이디어처럼 보이며 원래 작성자의 자존심에 보답하지만 진화할 수 없고 지역(원본이 아닌) 컨텍스트에 적응할 수 없기 때문에 결과를 실제로 사용하려고 하는 사람에게는 PITA입니다.

프록시 서버:

쉬운 디버깅을 위해 $GOPROXY는 로컬 트리를 가리키는 file:/// URL일 수도 있습니다.

zip 형식의 타사 모듈이 포함된 디렉토리를 가리키는 https:/// URL의 file:///과 함께 작동하도록 하십시오(다른 모든 항목 제외).

이는 엔티티가 동일한 타사 프로젝트 목록의 하위 집합에 의존하는 여러 개발 팀의 작업을 조정하는 가장 간단한 방법입니다. "좋은" 타사 릴리스를 검토하고 배포할 책임이 있는 QA/법무/보안 담당자를 두십시오. 공통 디렉토리에 있고 다른 모든 사람들이 이 공통 디렉토리에서 사용 가능한 모듈에 따라 작업을 수행하도록 합니다.

그렇게 하면 다른 사람의 작업과 호환되지 않는 버전에서 작업을 시작하는 사람이 없고 다른 팀에서 이미 식별한 버그가 있거나 위험한 버전에 머무르는 사람이 없으며 개발자 스테이션이 동일한 사본의 다운로드를 계속 기다리고 있지 않다는 것을 확신할 수 있습니다. 이미 로컬에서 사용 가능한 소프트웨어

@Merovius 나는 동의하지 않지만, 우리가 주제에서 벗어나고 있으며 문제 토론을 방해하고 싶지 않다고 생각합니다. 그러나 다른 매체에서 후속 조치를 취하게 되어 기쁩니다. (내 이메일은 내 github 프로필에 있고 나는 Gophers slack의 joeshaw입니다.)

https://github.com/golang/go/issues/24301#issuecomment -374882685, @tpng :

의사 버전(v0.0.0-yyyymmddhhmmss-commit)의 타임스탬프에 어떤 시간대가 사용됩니까?

편집에서 언급했듯이 UTC. 그러나 절대 입력할 필요가 없다는 점에 유의하십시오. git 커밋 해시(접두사)를 입력하면 vgo가 올바른 의사 버전을 계산하고 대체합니다.

https://github.com/golang/go/issues/24301#issuecomment -374907338, @AlexRouSg :

C 의존성을 다룰 것인가?

https://github.com/golang/go/issues/24301#issuecomment -376606788, @stevvooe :

protobufs 또는 c 파일과 같은 Go가 아닌 리소스는 어떻게 됩니까?

https://github.com/golang/go/issues/24301#issuecomment -377186949, @nim-nim:

vgo 제안은 makefile을 불필요하게 만든 것을 축하합니다. 이것은 사실이 아닙니다. [생성된 코드에 대한 논의.]

Non-Go 개발은 계속해서 go 명령의 목표가 아니므로 C 라이브러리 관리 등을 지원하지 않으며 프로토콜 버퍼에 대한 명시적인 지원도 없을 것입니다.

그렇긴 하지만 Go에서 프로토콜 버퍼를 사용하는 것이 너무 어렵다는 것을 확실히 이해하고 있으며 별도로 해결되었으면 합니다.

보다 일반적으로 생성된 코드의 경우 실제 언어 간 빌드 시스템이 답입니다. 특히 모든 사용자가 올바른 생성기를 설치할 필요가 없기 때문입니다. 작성자가 생성기를 실행하고 결과를 확인하는 것이 좋습니다.

https://github.com/golang/go/issues/24301#issuecomment -375248753, @mrkanister :

기본 분기를 마스터에서 v2로 변경할 수 있다는 것을 알고 있지만, 새 주 버전을 릴리스할 때마다 업데이트해야 하는 작업이 여전히 남아 있습니다. 개인적으로 마스터와 v1 브랜치가 있으면 좋겠지만 이것이 제안서에 정확히 맞는지는 잘 모르겠습니다.

@AlexRouSg 및 다른 사람들이 지적했듯이 이렇게 할 수 있습니다. 나는 단지 그들의 대답을 확인하고 싶었을 뿐입니다. FAQ에도 추가하겠습니다.

https://github.com/golang/go/issues/24301#issuecomment -375989173, @aarondl :

이것이 지금 작동하지만 의도한 것입니까?

확실히 맞아요.

@jamiethermo , Perforce 및 다른 디렉토리의 분기에 대한 의견을 보내주셔서 감사합니다. 그 기능에 대해 잊어버렸지만 아마도 그것이 vgo에서 허용하는 것이 중요하다는 것을 확신시킨 이유일 것입니다.

https://github.com/golang/go/issues/24301#issuecomment -376925845에서 시작하여 벤더링과 프록시에 대한 좋은 토론이 있었습니다. 여기에는 분명히 두 가지 별개의 우려 사항이 있습니다.

오픈 소스 개발자는 인프라에 의존하지 않으려는 경향이 있으므로 @joeshaw 가 쓴 것처럼 벤더링을 원합니다. 확인을 위해 제한된 형식으로 계속 작동할 것입니다(go 명령을 실행하는 전체 대상 모듈의 최상위 수준에 있는 공급업체 디렉토리만).

엔터프라이즈 개발자는 인프라에 의존하는 데 아무런 문제가 없습니다. 이는 또 다른 비용일 뿐입니다. 특히 모든 리포지토리에서 모든 공급업체 코드를 복제하지 않고 모든 것을 동기화 상태로 유지하는 데 시간을 소비해야 하는 것과 같이 더 큰 비용 절감을 가져오는 경우에는 더욱 그렇습니다. 본질적으로 우리가 이야기한 모든 회사는 @jamiethermo 가 요청한 대로 벤더링이 아닌 프록시/미러를 원합니다. 우리는 그것이 작동하는지 확인합니다.

또한 모든 오픈 소스 개발자가 벤더가 필요하다고 느끼지 않도록 개발자가 신뢰하고 의지할 수 있는 공유 미러 네트워크를 구축하고 싶습니다. 하지만 그건 나중에. 첫 번째 vgo는 go가 되어야 합니다.

https://github.com/golang/go/issues/24301#issuecomment -377220411, @nim-nim:

zip 형식의 타사 모듈이 포함된 디렉터리를 가리키는 https:/// URL의 file:///과 함께 작동하도록 하십시오(다른 모든 항목 제외).

나는 "다른 모든 것을 제외"라고 말함으로써 당신이 무엇을 요구하는지 정확히 모르겠습니다. $GOPROXY가 설정된 경우 vgo는 해당 프록시에 요청합니다. 결코 다른 곳으로 떨어지지 않습니다. 해당 프록시는 대부분 zip 형식의 타사 모듈인 정적 파일 트리에서 제공할 수 있습니다. 파일 트리는 탐색 및 조회를 위해 다른 메타데이터 파일도 포함해야 합니다. HTTP는 디렉토리 목록과 같은 작업을 수행하는 표준 방법을 제공하지 않기 때문에 이러한 추가 파일은 피할 수 없습니다.

https://github.com/golang/go/issues/24301#issuecomment -377186949, @nim-nim:

와, 댓글이 깁니다. 나는 당신이 쓴 대부분의 내용에 동의한다고 생각합니다. 귀하의 게시물에서 마지막 글머리 기호에 응답하고 싶습니다.

• 고화질 재구축은 완벽한 픽셀 웹사이트와 유사합니다. 그것들은 분명히 좋은 아이디어처럼 보이며 원래 작성자의 자존심에 보답하지만 진화할 수 없고 지역(원본이 아닌) 컨텍스트에 적응할 수 없기 때문에 결과를 실제로 사용하려고 하는 사람에게는 PITA입니다.

잠금 파일은 픽셀 단위의 완벽한 웹사이트와 같다고 생각합니다. 이와 대조적으로 충실도가 높은 빌드는 컨텍스트가 변경됨에 따라 점진적으로 저하됩니다. 기본적으로 빌드는 B 1.2 및 C 1.4를 사용합니다. 그러나 B 1.3이 필요한 더 큰 빌드의 일부인 경우 B 1.3과 함께 사용할 수 있지만 업그레이드에 대한 구체적인 요구 사항이 없는 한 C 1.4(새 버전이 존재하더라도)를 유지합니다. 따라서 매우 충실도가 높은 빌드는 두 세계의 장점입니다. 가능한 한 원본에 충실하지만 불가능할 때 완벽한 픽셀을 고집하지는 않습니다.

https://github.com/golang/go/issues/24301#issuecomment -375415904, @flibustenet :

@rsc 로드맵과 우리가 지금 해야 할 일에 대해 좀 더 정확히 알려주셨으면 합니다.
Go 정책을 따르고 3개월(지금 2)에 vgo 기능을 중지합니까?

Vgo는 프로토타입이며 단독으로 출시되지 않습니다. 동결 등의 대상이 되지 않습니다. 그러나 이 제안은 아이디어와 대부분의 코드를 기본 cmd/go로 옮기는 것입니다. 릴리스의 일부로 cmd/go는 확실히 동결될 수 있습니다. 옵트인이고 vgo 관련 코드가 go 명령의 나머지 작업과 상당히 잘 분리되어 있기 때문에 vgo 관련 부분에 대한 작업은 위험이 상당히 낮고 몇 주 동안 그 중 일부가 계속되는 것을 볼 수 있습니다. 동결에. 지금은 제안 논의와 조정에 집중하고 있습니다. 제안서가 심각한 문제 없이 양호한 형태로 보이면 코드를 cmd/go로 이동합니다.

이제 모든 libs 관리자에게 go.mod 파일을 추가하도록 요청하는 순례자의 지휘봉을 따라가야 합니까, 아니면 제안이 공식적으로 수락될 때까지 기다려야 합니까(이름과 구문이 변경되지 않도록)?

go.mod 구문이 변경될 가능성이 있다고 생각합니다(이 문제 보기). 그러나 제안서에서 언급했듯이 우리는 계속 오래된 구문을 계속 사용할 것이고 vgo는 기존 파일을 업데이트할 것이므로 큰 문제는 아닙니다. 즉, 코드가 cmd/go의 개발 사본에 들어갈 때까지 찾을 수 있는 모든 라이브러리에 PR을 보내려고 하지 않을 것입니다.

https://github.com/golang/go/issues/24301#issuecomment -376640804, @pbx0 :

(오늘) vgo를 사용하여 빌드에 패키지 버전이 1개 이상인지 확인하는 것이 쉽습니까?

오늘 할 수 있는 가장 쉬운 일은 바이너리를 빌드한 다음 goversion -m을 실행하는 것입니다(https://research.swtch.com/vgo-repro 참조). 보다 일반적인 모듈 인식 go 목록이 있으면 바이너리를 먼저 빌드하지 않고도 동일한 작업을 수행할 수 있어야 합니다.

https://github.com/golang/go/issues/24301#issuecomment -376236546, @buro9 :

[microcosm-cc/ bluemonday@a5d7ef6과 같이 이전 버전과 호환되지 않는 보안 변경을 할 수 있습니까? ]

@Merovius 가 말했듯이 Go 1 호환성 지침 을 채택하면 주요 버전을 충돌시키지 않고 보안 변경이 명시적으로 허용됩니다.

즉, 보안을 위해 뭔가를 해야 하는 경우에도 여전히 최소한의 중단을 위해 노력해야 합니다. 당신이 링크한 커밋은 필요 이상으로 파괴적이며, 미래의 상황에서는 "보안 문제를 제거하면서도 가능한 한 적은 수의 클라이언트를 중단시키는 방법은 무엇입니까?"라는 관점에서 이러한 변경에 접근하는 것이 좋습니다. "

예를 들어, 기능을 제거하지 마십시오. 대신, 부적절하게 호출된 경우에만 함수를 패닉 또는 log.Fatal로 만듭니다.

이 경우 AllowDocType을 삭제하는 대신 보안 설정이므로 그대로 유지하고 AllowDocType(false)을 계속 수락했습니다. 누군가 -allowdoctype 플래그가 있는 명령줄 프로그램과 같이 라이브러리에 대한 래퍼를 작성했다면 최소한 해당 플래그가 없는 프로그램 사용은 계속 작동할 것입니다.

그리고 그 이상으로 doctype이 완전히 확인되지 않은 것이 걱정인 것 같지만 가장 일반적인 사용을 유지하기 위해 최소한의 확인을 하고 나머지는 보수적으로 거부했을 것입니다. 예를 들어, 최소한 &#<>\ 문자가 없는 따옴표 붙은 문자열로 ..> 를 계속 허용하고 또 허용하려고 했을 것입니다.

https://github.com/golang/go/issues/24301#issuecomment -375090551, @TocarIP :

[신속하게 업데이트를 받지 못하는 것에 대한 우려.]

최소한의 버전 선택에서는 전체 빌드가 최신 버전으로 업데이트되는 것을 방지하기 위해 하나의 종속성이 _불가능_하기 때문에 그 반대가 발생할 것이라고 생각합니다. 프로그램이 더 최신일 수 있습니다.

@Merovius 가 https://github.com/golang/go/issues/24301#issuecomment -375992900에 쓴 내용이 저에게 정확히 맞습니다. 요점은 업데이트를 요청할 때만 업데이트를 받으므로 예상하고 테스트, 디버그 등을 수행할 준비가 된 경우에만 문제가 (잠재적으로) 중단된다는 것입니다. 당신은 그것들을 요구해야 하지만 잠금 파일이 있는 다른 시스템보다 훨씬 더 자주는 아닙니다. 또한 "사용되지 않는/안전하지 않은 버전으로 빌드 중입니다"와 같은 경고를 표시하기 쉽게 만들고 싶습니다. 그러나 비업데이트 작업의 부작용으로 조용히 업데이트하지 않는 것이 중요합니다.

FAQ에도 추가되었습니다.

지금까지 훌륭한 토론을 하고 서로의 질문에 답변해 주신 모든 분들께 감사드립니다. 많은 사람들의 훌륭한 답변이지만 @Merovius 와 @kardianos에게 특별한 감사를 드립니다. FAQ https://github.com/golang/go/issues/24301#issuecomment -371228664 및 토론 요약 https://github.com/golang/go/issues/24301#issuecomment -371228742를 업데이트했습니다. 아직 대답하지 않은 세 가지 중요한 질문이 있습니다(요약에서 TODO라고 함). 이에 대해서는 다음에 작업하겠습니다. :-)

@rsc , #24057에는 zip 대신 tar를 사용하는 방법에 대한 논의가 있습니다.

https://github.com/golang/go/issues/24301#issuecomment -375106068, @leonklingele :

현재 알려진 대로 go get에 대한 지원이 더 이상 사용되지 않고 결국 제거될 경우 Go 바이너리를 가져오고 설치(태그 없는)하는 데 권장되는 방법은 무엇입니까?

여전히 갈 것입니다. 바이너리의 저장소에 태그가 지정되지 않은 경우 go get은 최신 커밋을 사용합니다. 그러나 실제로 바이너리를 퍼블리싱하는 사람들은 포함된 저장소에 라이브러리(또는 혼합)를 포함하는 저장소와 동일하게 태그를 지정하도록 권장되어야 합니다.

$GOPATH가 더 이상 사용되지 않는 경우 이러한 바이너리는 어디에 설치됩니까?

더 이상 $GOPATH에서 작업할 필요가 없지만 코드는 여전히 $GOPATH에 나열된 첫 번째 디렉토리에 작성됩니다. 이는 소스 캐시입니다. vgo를 사용한 후 $GOPATH/src/v를 참조하십시오. 바이너리는 $GOPATH/bin에 설치됩니다. 몇 가지 릴리스 이전에는 $GOPATH를 설정할 필요가 없습니다. 기본값은 $HOME/go입니다. 따라서 개발자는 $GOPATH를 설정하거나 그것이 무엇인지 알지 못하는 것에 대해 걱정하지 않고 자신의 바이너리가 $HOME/go/bin에 있다는 것을 알게 됩니다. $GOBIN을 사용하여 해당 위치를 재정의할 수 있습니다.

@dsnet , 감사합니다 토론 요약에 링크를 추가했습니다. 그 논의를 거기에 두도록 합시다.

$GOPROXY가 설정된 경우 vgo는 해당 프록시에 요청합니다. 결코 다른 곳으로 떨어지지 않습니다. 해당 프록시는 대부분 zip 형식의 타사 모듈인 정적 파일 트리에서 제공할 수 있습니다. 파일 트리는 탐색 및 조회를 위해 다른 메타데이터 파일도 포함해야 합니다. HTTP는 디렉토리 목록과 같은 작업을 수행하는 표준 방법을 제공하지 않기 때문에 이러한 추가 파일은 피할 수 없습니다.

원래 모듈이 zip 형식으로 유지되는 한 변조하려는 유혹을 제거하고 인덱서가 견고하고 가벼우면 괜찮습니다.

목록 제약이 파일에 적용되지 않고 lftp와 같은 유틸리티는 오래된 http 디렉토리를 나열할 수 있었습니다(주요 http 서버에서 작동하는 경우 비표준인지 여부는 중요하지 않음). 따라서 인덱스가 없는 운영은 인프라에 투자하기를 원하지 않는 소규모 기업에 가능하고 바람직할 수 있습니다. yum/dnf/zipper는 또한 사용자 정의 색인에 의존하며 공유 디렉토리 색인을 얻는 것이 일부 조직에서 생각하는 것처럼 항상 간단한 것은 아닙니다.

오픈 소스 개발자는 인프라에 의존하지 않으려는 경향이 있으므로 @joeshaw 가 쓴 것처럼 벤더링을 원합니다.

그렇지 않습니다. 오픈 소스 개발자는 대부분 전체 프로세스가 공개되고 투명하기를 원하며 다른 사람의 좋은 바램에 의존할 필요가 없습니다. 따라서 인프라 자체가 오픈 소스이고 로컬 배포가 쉽고 저렴하다면 완벽하게 괜찮습니다. github와 같은 거대한 블랙박스 독점 사이트에 의존하는 것은 분명히 이 범주에 속하지 않지만 인프라와 같은 것은 아닙니다. 오픈 소스 사람들은 다른 사람들보다 수십 년 앞서 미러링을 했습니다. 그들이 받아들이지 않는 것은 닫혀 있고 미러를 설정하는 데 비용이 많이 듭니다(오픈 소스 용어로 비용이 많이 드는 것은 인간의 시간으로 측정됨)

개방적이고 쉽고 저렴한 벤더링의 특성, 벤더링 프로세스 자체 및 사용되지 않는 타사 코드 버전에 대한 코드베이스의 점진적인 화석화를 조장하는 방식은 그다지 많지 않습니다.

엔터프라이즈 개발자는 인프라에 의존하는 데 문제가 없습니다. 이는 또 다른 비용일 뿐입니다.

Google에서 일하는 것은 정말 멋진 일입니다. , 문제를 보기 위해 누군가에게 비용을 지불하는 것을 정당화하기 위한 것이므로 모든 인프라 비용은 Go 도달 범위를 줄이고 새로운 구조에 의한 채택을 방지합니다.

기업은 오픈 소스와 같으며 저렴하고 쉬운 것에 관심이 있습니다. 그들은 개방에 대해 전혀 신경 쓰지 않았지만 이제는 그것이 저렴한 것과 상관관계가 있다는 것을 깨닫고 천천히 변화하고 있습니다(배포를 돕기 위해 값비싼 컨설팅과 함께 값비싼 블랙박스 솔루션을 전문으로 하던 전통적인 엔터프라이즈 공급업체의 당혹감에).

내부 IT를 최저 입찰자에게 계약하는 기업은 값싼 개발자가 인터넷에서 이해할 수 없는 손상되거나 위험한 코드를 다운로드하는 것을 확실히 원하지 않기 때문에 미러링을 확실히 고집할 것입니다. 그들은 문제가 있는지 로컬 미러 콘텐츠를 스캔하고 내부 IT가 독점적으로 사용하도록 강제하기 위해 인력과 도구에 비용을 지불할 것입니다.

또한 모든 오픈 소스 개발자가 벤더가 필요하다고 느끼지 않도록 개발자가 신뢰하고 의지할 수 있는 공유 미러 네트워크를 구축하고 싶습니다.

모듈을 포함하는 색인된 디렉토리의 참조 사본을 어딘가에 게시하기만 하면 됩니다. 특정 웹 서버 구성이 필요한 프록시와 같은 설정은 잊어버리십시오. 그것이 오픈 소스 작성자가 하는 일이며 자신을 미러링하는 데 어려움이 없습니다. 미러링이 디렉토리의 내용을 복사하고 특정 웹 서버 구성이 필요하지 않은 한 미러링하려는 조직이 많이 있습니다.

생성된 코드에 대해 더 일반적으로 말하면 실제 언어 간 빌드 시스템이 답입니다.

절대 일어나지 않을 일이라는 것을 저와 같이 알다시피 누군가는 항상 고유한 기능을 수행하는 새로운 언어를 발명하기를 원할 것입니다. 그것은 밀짚 논증입니다.

그렇다고 해서 Go가 할 수 있는 것과 할 수 없는 것에 대한 엄격한 지침과 함께 코드를 생성하는 모든 프로젝트별 프로세스를 시작하는 표준 명령을 정규화하는 것을 막지는 않습니다(일반적으로 표준 Go 명령에서 이미 다루는 작업은 수행하지 않아야 합니다. 이미 그대로).

특히 모든 사용자가 올바른 발전기를 설치할 필요가 없기 때문입니다. 작성자가 생성기를 실행하고 결과를 확인하는 것이 좋습니다.

현재로서는 버전 이식성에 대해 전혀 신경 쓰지 않고 생성 전에 소프트웨어 환경이 동결될 것으로 예상하기 때문에 기존 생성기가 구현되는 방식에 대한 대대적인 재고가 필요합니다. 생성이 재생성 없이 이후 버전 변경을 위험하게 만드는 직접적인 효과로. 사람이 원래 버전 세트에 대해서만 확인하므로 사람이 결과를 확인하는지 여부는 중요하지 않습니다. vgo는 이후 버전 변경을 수행할 수 있어야 합니다.

따라서 vgo는 조만간 재생성 문제를 해결해야 합니다. 나중에는 생성된 코드가 있는 경우 vgo 업데이트가 위험하다는 것을 프로젝트가 발견하기를 기다리는 것을 의미합니다.

https://github.com/golang/go/issues/24301#issuecomment -374791885, @jimmyfrasche :

이는 동일한 패키지의 여러 주요 버전이 결국 이를 수행할 수 있기 때문에 초기화 중에 다른 패키지에 자신을 등록하는 데이터베이스 드라이버 및 이미지 형식과 같은 것들에도 영향을 미칩니다. 그것이 어떤 영향을 미칠지는 나에게 분명하지 않습니다.

예, "프로그램에 이들 중 하나만 있을 것"이라고 가정하는 코드의 문제는 현실이며 우리 모두가 새로운(더 나은) 모범 사례 및 규칙을 수립하기 위해 해결해야 할 문제입니다. 나는 이 문제가 vgo에 의해 도입되었다고 생각하지 않으며, vgo는 틀림없이 상황을 이전보다 더 좋게 만듭니다.

일부 사람들은 vgo가 1.x와 2.x도 함께 있을 수 없다는 Dep의 규칙을 채택해야 한다고 주장하지만, 이는 우리가 Go로 목표로 하는 대규모 코드 기반으로 확장되지 않는다는 점을 이해합니다. vgo-import 게시물에서 볼 수 있듯이 전체 대형 프로그램이 한 API에서 다른 API로 한 번에 업그레이드될 것이라고 기대하는 것은 불가능합니다. 본질적으로 다른 모든 패키지 관리자는 같은 이유로 1.x와 2.x를 함께 허용한다고 생각합니다. 확실히 화물은 그렇습니다.

일반적으로 vgo는 벤더링에 비해 중복을 줄입니다. 벤더링을 사용하면 주어진 패키지의 1.2, 1.3 및 1.4가 모두 하나의 바이너리로 끝나거나 1.2의 3개 사본이 될 수도 있습니다. 적어도 vgo는 가능한 중복을 하나의 1.x, 하나의 2.x 등으로 잘라냅니다.

이미 다른 패키지의 작성자가 동일한 것을 등록하지 않도록 해야 하는 경우입니다. 예를 들어, expvar는 http.Handle("/debug/vars")를 수행하고 본질적으로 해당 경로에 대한 소유권을 주장했습니다. Awesome.io/supervars와 같은 타사 패키지가 동일한 경로를 등록하려고 시도하지 않아야 한다는 데 모두 동의하기를 바랍니다. 이는 단일 패키지의 여러 버전 간에 충돌을 남깁니다.

우리가 expvar/v2를 도입한다면, 그것은 끝내 굉장한.io/supervars와 같은 두 번째, 다른 패키지가 되며 큰 빌드에서 expvar와 충돌할 수 있습니다. 그러나 supervar와 달리 expvar/v2는 expvar와 같은 사람이나 팀이 소유하므로 두 패키지가 등록을 공유하도록 조정할 수 있습니다. 다음과 같이 작동합니다. v2를 작성하기로 결정하기 전에 expvar v1.5.0이 마지막이므로 v1.5.0에 http.Handle이 있다고 가정합니다. v2가 v1을 대체하기를 원하므로 http.Handle을 v2.0.0으로 이동하고 v1이 v2로 호출을 전달할 수 있도록 v2에 API를 추가합니다. 그런 다음 이 전달로 구현되는 v1.6.0을 만듭니다. v1.6.0은 http.Handle을 호출하지 않습니다. v2.0.0에 위임합니다. 이제 expvar v1.6.0과 expvar/v2가 공존할 수 있습니다. 우리가 그렇게 계획했기 때문입니다. 유일한 문제는 빌드가 expvar/v2와 함께 expvar v1.5.0을 사용하는 경우 어떻게 됩니까? 그런 일이 발생하지 않도록 해야 합니다. expvar/v2가 v1.6.0(또는 그 이상)에서 expvar를 필요로 하도록 함으로써 그 방향으로 가져오기가 없지만 물론 expvar v1.6.0은 API를 호출하기 위해 v2.0.0 이상에서 expvar/v2가 필요합니다. . 이 요구 사항 주기를 통해 v1.5.0과 v2가 절대 혼합되지 않도록 할 수 있습니다. 이러한 종류의 교차 주요 버전 조정에 대한 계획은 최소 버전 선택 이 요구 사항 그래프에서 주기를 허용하는 바로 그 이유입니다.

요구 사항 그래프의 주기 허용과 결합된 "단 하나의 주요 버전" 규칙은 작성자에게 모듈의 서로 다른 주요 버전 간에 싱글톤의 적절한 조정(및 싱글톤 소유권 마이그레이션)을 관리하는 데 필요한 도구를 제공합니다. 문제를 제거할 수는 없지만 작성자에게 문제를 해결하는 데 필요한 도구를 제공할 수는 있습니다.

특히 프로토콜 버퍼에는 등록 문제가 있으며 프로토콜 .pb.go 파일이 프로젝트에 전달되고 복사되는 매우 임시적인 방식으로 인해 이러한 문제가 악화된다는 것을 알고 있습니다. 그것은 다시 대부분 vgo와 독립적인 것입니다. 수정해야 하지만 vgo가 아니라 Go 프로토콜 버퍼가 사용되는 방식을 변경해야 합니다.

https://github.com/golang/go/issues/24301#issuecomment -374739116, @ChrisHines :

vgo 이전 세계와 vgo 세계 사이의 마이그레이션 경로가 나빠지는 것이 가장 걱정입니다. [자세한 세부 사항]

이것이 제안서에 대한 첫 번째 의견이어서 정말 기쁩니다. 확실히 맞추는 것이 가장 중요합니다.

이전 go get 및 무수한 벤더링 도구에서 새 모듈 시스템으로의 전환은 믿을 수 없을 정도로 원활하게 실행되어야 합니다. 나는 그것이 정확히 어떻게 작동할 것인지에 대해 최근에 많이 생각했습니다.

원래 제안은 개발자에게 v2/라는 repo 하위 디렉토리에 모듈의 버전 2를 넣을 수 있는 옵션을 허용합니다. 이 옵션을 실행하면 개발자가 의미론적 가져오기 버전 관리를 사용하고 모듈과 호환되지만 이전 "go get"과도 이전 버전과 호환되는 리포지토리를 만들 수 있습니다. 이 옵션을 설명하는 게시물은 대다수의 프로젝트가 이 옵션을 사용하고 싶어하지 않을 것임을 인정합니다. 프로젝트가 이미 v2 이상인 경우에만 호환성을 위해 필요합니다. 동시에 v2 이상에서 널리 사용되는 대규모 프로젝트의 수를 과소평가했습니다. 예를 들어:

• github.com/godbus/dbus는 v4.1.0에 있습니다(462 패키지에서 가져옴).
• github.com/coreos/etcd/clientv3는 v3.3.3에 있습니다(799 패키지에서 가져옴).
• k8s.io/client-go/kubernetes는 v6.0.0에 있습니다(1928 패키지에서 가져옴).

클라이언트가 손상되는 것을 방지하려면 모든 클라이언트가 모듈을 사용한다고 가정할 수 있을 때까지 해당 프로젝트를 하위 디렉토리로 이동한 다음 다시 루트로 이동해야 합니다. 물어볼게 많습니다.

git 하위 모듈로 트릭을 수행하는 또 다른 옵션입니다. 이전 go get 명령은 repo의 기본 분기보다 "go1"이라는 태그 또는 분기를 선호하므로 원활한 전환을 활성화하려는 프로젝트는 "v2" 하위 디렉토리만 설정된 "go1" 분기에 커밋을 만들 수 있습니다. 실제 repo 루트를 다시 가리키는 git 하위 모듈로. "go get"이 해당 go1 분기 및 채워진 하위 모듈을 체크아웃하면 올바른 파일 트리 레이아웃이 표시됩니다. 그것은 일종의 끔찍하지만 새 릴리스가 만들어질 때마다 하위 모듈 포인터를 업데이트해야 합니다.

이 두 가지 모두 작성자가 사용자를 손상시키지 않도록 조치를 취해야 하는 불행한 영향을 미치며 심지어 새 릴리스에 대해서만 적용됩니다. 대신 사용자의 코드가 작성자의 추가 작업 없이도 계속 작동하고 이상적으로는 이전 릴리스에서도 작동하기를 바랍니다.

그러나 이것이 내가 모듈 세계로 전환할 때 수정되지 않은 상태로 작동하도록 할 수 있는 유일한 방법입니다. 그렇지 않은 경우 대안은 old go get을 수정하는 것입니다. 이는 실제로 old go 빌드를 수정함을 의미합니다.

기본적으로 두 가지 다른 가져오기 경로 규칙이 있습니다. 이전 버전은 메이저 버전이 없고 새 버전은 v2 이상의 메이저 버전이 있습니다. 이전 트리의 코드는 아마도 이전 규칙을 사용하는 반면 새 트리의 코드(go.mod 파일이 포함된 디렉토리 아래)는 아마도 새 규칙을 사용할 것입니다. 전환하는 동안 두 규칙이 겹치도록 하는 방법이 필요합니다. 시맨틱 가져오기 버전 관리에 대해 약간의 정보를 얻으라고 old go를 가르친다면 중복되는 양을 상당히 늘릴 수 있습니다.

제안된 변경 사항: "새" 코드를 동일한 디렉토리 또는 상위 디렉토리에 go.mod 파일이 있는 코드로 정의하십시오. 이전 go get은 항상 그랬던 것처럼 코드를 계속 다운로드해야 합니다. "go build" 단계에서 "new" 코드의 가져오기 처리를 조정할 것을 제안합니다. 특히, 새 코드의 가져오기가 x/y/v2/z라고 표시되지만 x/y/v2/z가 존재하지 않고 x/y/go.mod가 "module x/y/v2"라고 표시되면 go build는 다음을 읽습니다. 대신 x/y/z로 가져옵니다. 이 업데이트를 Go 1.9 및 Go 1.10의 포인트 릴리스로 푸시합니다.

업데이트 : #25069에 복사되었습니다.

이러한 변경으로 인해 해당 패키지가 저장소 구성에 "주요 분기" 또는 "주 하위 디렉터리" 접근 방식을 선택하는지 여부에 관계없이 모듈 인식 패키지가 최신 버전의 모듈 인식 패키지를 사용할 수 있어야 합니다. 더 이상 하위 디렉토리 접근 방식으로 강제되지는 않지만 여전히 작동하는 옵션입니다. 그리고 이전 Go 릴리스를 사용하는 개발자는 여전히 코드를 빌드할 수 있습니다(적어도 포인트 릴리스로 업데이트한 후).

@rsc 저는 vgo로의 전환도 어떻게 할 수 있는지 알아내려고 노력했습니다. 귀하의 응답에서 제시한 것과 동일한 결론에 도달했으며 귀하의 제안은 제가 생각해낸 최고의 접근 방식과 일치합니다. 내 스스로. 제안한 변경 사항이 마음에 듭니다.

https://github.com/golang/go/issues/24301#issuecomment -377527249, @rsc :

그런 다음 이 전달로 구현되는 v1.6.0을 만듭니다. v1.6.0은 http.Handle을 호출하지 않습니다. v2.0.0에 위임합니다. 이제 expvar v1.6.0과 expvar/v2가 공존할 수 있습니다. 우리가 그렇게 계획했기 때문입니다.

이것은 그것보다 더 쉽게 들립니다. 실제로, 대부분의 경우 이것은 v1.6.0이 v2 래퍼 형태로 v1을 완전히 다시 작성해야 함을 의미합니다. _(http.Handle에 대한 전달 호출은 v2에서 하나의 다른 핸들러를 등록하게 됩니다. 이는 차례로 모든 관련됨을 의미합니다. 코드는 또한 등록된 핸들러와 올바르게 상호 작용하려면 v2에서 가져온 것이어야 합니다)_.

이것은 v2가 진화함에 따라 특히 시간이 지남에 따라 v1 동작에 대한 미묘한 세부 사항을 변경할 가능성이 매우 높습니다. 이러한 미묘한 세부 변경 사항을 보상하고 v1.6.x에서 충분히 좋은 v1을 에뮬레이트할 수 있다고 해도 - 여전히 많은 추가 작업이 필요하고 v1 분기의 향후 지원을 만들 가능성이 매우 높습니다(v1.5.0의 후속 제품을 의미합니다. 여기) 무의미하다.

@powerman , 나는 이것이 사소하다고 말하는 것이 절대 아닙니다. 그리고 v1과 v2가 http 등록과 같은 일부 공유 리소스를 놓고 싸우는 정도로만 조정하면 됩니다. 그러나 이 패키징 생태계에 참여하는 개발자는 패키지의 v1과 v2가 대규모 프로그램에서 공존해야 한다는 점을 절대적으로 이해해야 합니다. 많은 패키지는 작업이 필요하지 않습니다. 예를 들어 yaml과 blackfriday는 모두 v1과 완전히 다른 v2에 있지만 싸울 공유 상태가 없으므로 명시적인 조정이 필요하지 않지만 다른 패키지는 필요합니다.

@powerman @rsc
"메인" 스레드를 사용하기 때문에 2개 이상의 인스턴스도 가질 수 없다는 것을 의미하는 GUI 패키지를 개발 중입니다. 그래서 최악의 경우 싱글톤 시나리오에서 이것이 내가 하기로 결정한 것입니다.

• v0/v1 릴리스만 있으므로 2개 이상의 버전을 가져올 수 없습니다.

• 자체 API 버전 폴더에 공개 코드가 있어야 합니다(예: vgo가 허용한다고 가정하는 v1/v2 또는 api1/api2).

• 그런 다음 이러한 공개 API 패키지는 내부 패키지에 의존하므로 v2에서 다시 작성하는 대신 패키지가 커짐에 따라 롤링 다시 작성하고 처리하기가 훨씬 쉽습니다.

https://github.com/golang/go/issues/24301#issuecomment -377529520에서 제안된 변경 사항은 "새" 코드를 동일한 디렉토리 또는 상위 디렉토리에 go.mod 파일이 있는 코드로 정의합니다. 여기에는 예를 들어 Gopkg.toml에서 종속성을 읽어서 생성된 "합성된" go.mod 파일이 포함됩니까?

@zeebo 네. 트리에 go.mod 파일이 있는 경우 코드는 실제로 vgo로 빌드된다고 가정합니다. 그렇지 않은 경우 rm go.mod(또는 적어도 다른 사람들이 찾을 수 있는 저장소에 체크인하지 마십시오).

@AlexRouSg , GUI 패키지에 대한 귀하의 계획은 나에게 의미가 있습니다.

@rsc 흠.. 이해가 잘 안가서 불명확했다면 죄송합니다. 파일 트리에 Gopkg.toml만 있는 패키지는 정의에 대해 "새 항목"으로 계산됩니까?

@rsc

보다 일반적으로 생성된 코드의 경우 실제 언어 간 빌드 시스템이 답입니다. 특히 모든 사용자가 올바른 생성기를 설치할 필요가 없기 때문입니다. 작성자가 생성기를 실행하고 결과를 확인하는 것이 좋습니다.

우리는 protobuf를 GOPATH에 매핑하여 이 문제를 해결했습니다. 예, 일반 사용자는 업데이트할 도구가 필요하지 않지만 protobuf를 수정하고 재생성하는 사용자에게는 protobuild의 솔루션이 매우 잘 작동합니다.

여기에 대한 대답은 상당히 실망스럽습니다. 존재하지 않는 새로운 빌드 시스템을 찾는 것은 답이 아닙니다. 여기서 현실은 우리가 이러한 빌드 시스템을 재구축하지 않고 새로운 vgo 시스템의 채택을 피하면서 작동하는 것을 계속 사용한다는 것입니다.

vgo 는 GOPATH를 좋아하고 채택했으며 문제를 해결한 사람들에게 파산을 선언합니까?

@zeebo , 아니요, Gopkg.toml이 있는 것은 새 것으로 간주되지 않습니다. 여기서 "new"는 vgo 스타일(의미론적 가져오기 버전 관리) 가져오기를 사용할 것으로 예상됨을 의미합니다.

@stevvooe :

우리는 protobuf를 GOPATH에 매핑하여 이 문제를 해결했습니다. ...
vgo는 GOPATH를 좋아하고 채택하고 문제를 해결한 사람들에게 파산을 선언합니까?

나는 당신의 프로토빌드를 보지 않았지만 일반적으로 예, 우리는 비 GOPATH 모델로 이동하고 있으며 GOPATH가 활성화했을 수 있는 몇 가지 트릭은 뒤에 남겨질 것입니다. 예를 들어 GOPATH를 사용하면 원래 godep이 공급업체 지원 없이 공급업체를 시뮬레이션할 수 있습니다. 더 이상 불가능합니다. 얼핏 보면 protobuild는 파일(pb.go)을 사용자가 소유하지 않은 다른 패키지에 삭제할 수 있다는 가정을 기반으로 하는 것처럼 보입니다. 그런 종류의 글로벌 작업은 더 이상 지원되지 않습니다. 저는 vgo와 별개로 protobuf가 잘 지원되는지 확인하고자 하는 것에 대해 완전히 진지하고 진지합니다. @neild 는 제안을 듣는 데 관심이 있을 수 있지만 이 문제에 대해서는 그렇지 않을 수 있습니다.

@stevvooe 는 https://github.com/golang/go/issues/24301#issuecomment -377602765 에서 @rsc 의 의견을 제공했습니다. 그 문제는 vgo 각도를 다룹니다. 일이 다른 곳에서 처리되면 @dsnet 등이 우리에게 신호를 보낼 것이라고 확신합니다.

참고: 이전 댓글을 자세히 보지 못했습니다. 다른 접근 방식으로 문제가 해결된 것 같습니다. 아래는 제 생각이었습니다.

그냥 아이디어입니다.

vgo-v1-lock과 같은 vgo get 인식 특정 태그를 만드는 것은 어떻습니까?
리포지토리에 태그가 있으면 다른 버전 태그를 무시하고 태그에 고정될 수 있습니다.

따라서 저장소가 v2.1.3을 마지막 버전으로 태그 지정하면
그러나 소유자는 v2.1.3 태그가 지정된 동일한 커밋에 vgo-v1-lock 태그를 푸시합니다.
go.mod를 쓸 수 있습니다.

require (
    "github.com/owner/repo" vgo-v1-lock
)

vgo get -u 인 경우에도 저장소 소유자가 태그를 변경하거나 제거할 때까지 업데이트되지 않아야 합니다.
큰 저장소가 이동을 준비하기 쉽게 만들 수 있습니다.

도서관 저자가 준비되면 저자는 사용자에게 알릴 수 있습니다.
가져오기 경로에 "/v2"를 넣어 수동으로 업데이트할 수 있습니다.

깊은 종속성을 패치해야 하는 경우(예: 원래 작성자가 아직 태그에서 릴리스하지 않은 CVE 수정 사항 적용)를 처리하는 방법은 무엇입니까? 원래 작성자 릴리스에 패치를 적용할 수 있기 때문에 공급업체 전략이 이를 처리할 수 있는 것 같습니다. vgo가 이것을 처리할 수 있는 방법을 보지 마십시오.

@chirino 에서 go.mod 파일의 replace 지시문을 사용하여 패치된 패키지를 가리킬 수 있습니다.

@rsc

얼핏 보면 protobuild는 파일(pb.go)을 사용자가 소유하지 않은 다른 패키지에 삭제할 수 있다는 가정을 기반으로 하는 것처럼 보입니다.

이것은 프로젝트가 하는 일이 아닙니다. GOPATH 및 공급업체 디렉토리에서 가져오기 경로를 작성합니다. 그러면 프로젝트의 모든 protobuf 파일이 해당 가져오기 경로로 생성됩니다. 또한 특정 Go 패키지로 가져오기를 매핑하는 것과 같은 작업도 수행합니다.

이것의 이점은 모든 것을 재생성하지 않고 종속성에 정의된 다른 protobuf에 종속된 리프 프로젝트에서 protobuf를 생성할 수 있다는 것입니다. GOPATH는 protobuf 파일의 가져오기 경로가 됩니다.

이 제안의 가장 큰 문제는 파일 시스템의 Go 패키지와 관련된 프로젝트의 파일을 해결할 수 있는 능력을 완전히 상실한다는 것입니다. 대부분의 포장 시스템은 어렵게 만들기는 하지만 이를 수행할 수 있는 기능이 있습니다. GOPATH는 이 작업을 수행하는 것이 매우 쉽다는 점에서 독특합니다.

@stevvooe 죄송하지만 protobuild가 하는 일에 대해 여전히 혼란스럽습니다. 새로운 문제 "x/vgo: protobuild와 호환되지 않음"을 제출하고 오늘날 존재하는 파일 트리의 간단한 작업 예, 트리에 추가하는 protobuild 및 vgo에서 작동하지 않는 이유를 제공할 수 있습니까? 감사 해요.

모듈 이름을 변경해야 하는 경우(도메인 분실, 소유권 변경, 상표 분쟁 등) 어떻게 됩니까?

@jimmyfrasche

사용자:
그런 다음 임시 수정 사항으로 go.mod 파일을 편집하여 동일한 가져오기 경로를 유지하면서 이전 모듈을 새 모듈로 교체할 수 있습니다. https://research.swtch.com/vgo-tour

그러나 장기적으로 모든 가져오기 경로를 변경하고 go.mod 파일을 편집하여 새 모듈을 사용하려고 합니다. 기본적으로 vgo를 사용하거나 사용하지 않고 수행해야 하는 것과 동일한 것입니다.

패키지 관리자로서:
모듈 가져오기 경로를 변경하고 사용자에게 변경 사항을 알리려면 go.mod 파일을 업데이트하기만 하면 됩니다.

@jimmyfrasche ,

모듈 이름을 변경해야 하는 경우(도메인 분실, 소유권 변경, 상표 분쟁 등) 어떻게 됩니까?

이것은 vgo 제안이 직접 해결하려고 시도하지 않는 실제 기존 문제이지만 분명히 우리는 결국 해결해야 합니다. 코드가 사라지는 것에 대한 답은 캐싱 프록시(미러)와 함께 이를 신뢰할 이유가 있는 것입니다. 그것이 미래의 일이다. 코드 이동에 대한 답은 유형 별칭이 유형 리디렉션인 것처럼 모듈 또는 패키지 리디렉션의 명시적 개념을 추가하는 것입니다. 그것은 미래의 일이기도 하다.

코드가 사라지는 것에 대한 답은 캐싱 프록시(미러)를 갖는 것입니다.

기업을 위한 IMO입니다. 대부분의 소규모 회사 및 기타 회사는 모든 종속성을 동일한 리포지토리에 공급하고 커밋하는 데 완벽합니다.

위에서 언급한 호환성을 위해 #24916을 제출했습니다.
또한 HTTPS 액세스를 주장하는 대신 git 등을 직접 사용하도록 제안하는 #24915를 제출했습니다. 코드 호스팅 설정이 아직 API 전용으로 준비되지 않은 것 같습니다.

계획된 vgo get 명령을 사용하여 모드 파일의 일관성을 만들기 위한 사소한 제안

"vgo-tour" 문서에서 vgo get 명령은 다음과 같이 표시됩니다.

vgo get rsc.io/[email protected]

모드 파일에서 이 형식을 미러링하는 것은 어떻습니까? 예를 들어:

module "github.com/you/hello"
require (
    "golang.org/x/text" v0.0.0-20180208041248-4e4a3210bb54
    "rsc.io/quote" v1.5.2
)

간단히 다음과 같을 수 있습니다.

module "github.com/you/hello"
require (
    "golang.org/x/[email protected]"
    "rsc.io/[email protected]"
)

• 명령줄과의 일관성 향상
• 단일 식별자는 항목을 완전히 정의합니다.
• 여러 버전의 패키지 식별자가 필요한 모드 파일에 정의된 작업을 지원하기 위한 더 나은 구조

이 제안이 "바이너리 전용" 패키지 배포를 처리하는 방법에 대한 더 명확한 정보를 찾고 있습니다.

바이너리 라이브러리 버전 관리/배포는 vgo에 대한 설명 문서에 표시되지 않는 것 같습니다. 이것을 더 주의 깊게 볼 필요가 있습니까?

오늘날 작동하는 방식으로 일반 git 도구를 사용할 수 있다면 go get 는 잘 작동합니다. 개인 Github 리포지토리 또는 내 Git 서버인지 여부는 중요하지 않습니다. 정말 좋아해요.

내가 이해한 바에 따르면 그런 식으로 계속 일하는 것은 불가능할 것입니다. 사실인가요? 그렇다면 코드를 체크아웃하기 위해 로컬에 설치된 git 바이너리를 사용하는 옵션을 유지할 수 있습니까? (명시적 CLI 플래그를 사용하는 이벤트)

@korya 최근 접수된 이슈를 확인해주세요 https://github.com/golang/go/issues/24915

@sdwarwick , https://github.com/golang/go/issues/24301#issuecomment -382791513(go.mod 구문), #24119 참조.

re https://github.com/golang/go/issues/24301#issuecomment -382793364, 무슨 말인지 이해가 가지 않을 수 있지만 go get은 바이너리 전용 패키지를 지원한 적이 없으며 계획도 없습니다. 지원을 추가합니다. 필요한 모든 가능한 다른 바이너리를 열거하는 것은 너무 어렵습니다. 소스가 필요하고 종속성 또는 컴파일러가 변경될 때 다시 컴파일할 수 있는 것이 좋습니다.

@rsc 나는 https://github.com/golang/go/issues/24301#issuecomment -382793364가 언급하고 있다고 생각합니다.
https://golang.org/pkg/go/build/#hdr -Binary_Only_Packages

@AlexRouSg 네. 그것들은 @rsc 가 언급하는 "go get"에서 지원되지 않습니다(그러나 "go build"는 빌드 유형으로 지원합니다). 이러한 유형의 패키지 배포는 "go get" 도구 외부에서 수행되어야 하므로 이 새로운 제안에서도 동일할 것입니다.

바이너리 전용 패키지에 대한 현재 지원은 지금까지처럼 제대로 작동하지 않을 것으로 예상합니다. 나는 그것을 제거하기 위해 최선을 다하지 않을 것입니다.

토론 요약을 다시 업데이트했습니다. 또한 이전 cmd/go의 최소 모듈 인식에 대한 제안을 위해 #25069를 제출했습니다.

@kybin , re https://github.com/golang/go/issues/24301#issuecomment -377662150 및 vgo-v1-lock 태그, 나는 항소를 보았지만 특별한 경우를 추가하는 것은 전체에 걸쳐 더 많은 특별한 경우를 추가한다는 것을 의미합니다 나머지 모듈 지원. 저는 이점이 이 경우 비용에 비례한다고 생각하지 않습니다. 사람들은 이미 유사 버전을 사용하여 유사한 효과를 얻을 수 있습니다. 나는 또한 태그가 이동하거나 사람들이 이전 버전과의 호환성을 적절하게 존중하지 않을까봐 걱정합니다(예: 의미론적 가져오기 버전 지정을 피하기 위해 vgo1-v1-lock을 v2.3.4에서 v3.0.0으로 이동). 그래서 균형 잡힌 생각으로 우리는 아마도 이것을 해서는 안 된다고 생각합니다.

이제 이 제안을 수락한 것으로 표시해야 할 때라고 생각합니다.

어떤 형태로든 받아들일 수 있을지에 대한 서스펜스는 없었습니다. 대신 여기에서 논의의 목표는 정확한 형식을 찾아 우리가 조정해야 할 대상을 식별하는 것이었습니다. 내가 블로그 게시물 에 쓴 것처럼 :

Go 개발자들이 우리가 알지 못하는 많은 영리한 방법으로 Go를 사용하기 때문에 Go 팀과 내가 볼 수 없는 문제가 있다는 것을 알고 있습니다. 제안 피드백 프로세스의 목표는 우리 모두가 현재 제안의 문제를 식별하고 해결하기 위해 협력하여 향후 Go 릴리스에서 제공되는 최종 구현이 가능한 한 많은 개발자에게 잘 작동하도록 하는 것입니다. 제안 토론 문제에 대한 문제점을 지적해 주십시오. 피드백이 도착하는 대로 토론 요약과 FAQ를 업데이트하겠습니다.

토론 요약 및 FAQ는 현재 최신 상태입니다. 여기에서의 토론과 문제 외의 토론으로 인해 다음과 같은 중요한 변경 사항이 발생했습니다.

• 이전 cmd/go, #25069의 최소 모듈 인식.
• 최소한의 공급업체 지원 복원, #25073.
• 직접 Git 액세스 지원 복원, #24915.
• go.mod, #24641에서 따옴표를 삭제하십시오.
• gopkg.in, #24099, 기타에 대한 더 나은 지원.
• 브랜치 식별자로 커밋 이름 지정 지원, #24045.

또한 go.mod 파일 이름과 구문을 변경할 수 있는지에 대한 토론이 촉발되었지만 결과적으로 변경된 사항은 따옴표를 삭제하는 것뿐이었습니다.

토론은 사라졌고 GitHub에 로드하는 것이 상당히 고통스러울 정도로 길어졌습니다(댓글 100개는 너무 많습니다!). 제안을 수락한 것으로 표시하면 vgo를 사용하고 Go 1.11에 "미리 보기"로 포함할 준비를 하는 데 집중할 수 있으며 GitHub에서 더 빨리 로드할 수 있는 문제로 이동할 수 있습니다.

물론 더 많은 버그를 찾아 수정해야 하며 더 많은 디자인 조정이 필요합니다. 이러한 세부 사항에 대한 논의는 해당 세부 사항과 관련된 새로운 문제에 대해 수행할 수 있습니다. "x/vgo:" 접두사와 vgo 마일스톤 을 사용하십시오.

감사합니다.

@rsc 지금 vgo를 시도하는 방법은 무엇입니까? github.com/golang/vgo 또는 github.com/golang/go를 가져와 빌드해야 하나요?

@ngrilly 계속 go get -u golang.org/x/vgo .

@rsc 이 제안에 많은 시간과 노력을 투자해 주셔서 감사합니다. Go 의존성 관리에 대한 좋은 이야기가 있는 지점에 결국 도달하기를 진심으로 바랍니다.

이제 이 제안을 승인으로 표시해야 할 때라고 생각합니다.

제안서를 제출한 개인이 승인될 준비가 되었을 때 선언하는 것은 적절하지 않다고 생각합니다. 제 생각에는 제안서를 제출하는 사람들, 특히 이렇게 크고 독단적인 제안서가 받아들여지는 것에 대해 발언권이 있어서는 안 된다고 생각합니다. 제안서 제출은 그들의 편견을 전달합니다. 반면에 작성자는 제안을 제기한 후 마음이 바뀌면 거부할 수 있는 권한이 분명히 있어야 한다고 생각합니다.

현재 vgo 내에서 기술적인 결정을 둘러싸고 심각한 불일치가 있는 것 같으며 생태계와 커뮤니티가 분열될까 두려워합니다. 이를 염두에 두고 경쟁 제안이 완료되고 스포트라이트를 받을 때까지 시간을 조금 더 허용해야 한다고 생각합니다. 그런 일이 발생하면 토론과 궁극적인 결정을 용이하게 하기 위해 여러 회사와 커뮤니티의 대표로 구성된 _중립적인 _ 파티가 필요합니다.

나는 바둑 리더십의 상당 부분이 바둑 뒤의 커뮤니티(이를 사용하는 다른 회사 포함)로부터 너무 고립되어 있고, 그 결과 언어와 생태계가 손상되기 시작했다는 우려가 커지고 있습니다. 이것이 바로 Go 프로그래밍 언어의 사용자를 반영하는 표현으로 이러한 제안을 비준하는 데 도움이 되는 중립적인 그룹이 필요하다고 생각하는 이유입니다.

궁극적으로 Google 내부에서 소프트웨어 엔지니어로 일하는 것은 업계의 많은 부분에 비해 다른 관점을 갖게 됩니다. 핵심 개발자의 임계량이 Google 내에 있다는 것은 앞으로 Go를 추진할 때 필요한 다양성에 기여하지 않습니다.

@theckman 귀하의 사고 방식은 다음과 같습니다.

1. Go에 대한 결정은 주로 Google 엔지니어로 구성된 소규모 팀에서 이루어집니다.
2. Google 엔지니어는 Google의 요구 사항이 매우 구체적이기 때문에 나머지 커뮤니티와 격리되어 있습니다.
3. 이는 Google의 관점을 선호하고 다른 Go 사용자에게 적용되지 않는 결정으로 이어집니다.
4. 이것은 Go 커뮤니티를 손상시키고 분열시킬 수 있습니다.
5. 이 문제를 해결하려면 Go 커뮤니티의 다양성을 반영하는 그룹("민주적"인 것)이 공동으로 결정을 내리는 공식 결정 프로세스를 Go에서 채택해야 합니다.

이론적으로는 "민주적"인 것을 좋아하지만 실제로는 다음과 같습니다.

• Go 팀이 내린 결정이 "소규모" Go 사용자를 희생시키면서 Google의 요구에 편향되어 있다고 생각하지 않습니다. 아주 작은 상점(Google과 정반대)의 개발자로서 Go가 우리의 요구 사항에 매우 잘 적응했다고 생각하고 제 주변의 다른 소규모 팀에서 Go를 즐겁게 사용하고 있다는 것을 알고 있습니다. 개인적으로 Go 언어에 대한 유일한 불만은 Go 팀(종속성 관리, 제네릭 부족, 장황한 오류 처리)에서 인정했으며 그들이 작업 중이라고 확신합니다. "민주적인" 절차가 있었다면 "나머지 커뮤니티"에 더 잘 봉사하고 달라졌을 바둑 팀이 내린 결정의 예를 제공할 수 있습니까?

• "민주적인" 의사결정 과정을 채택하면 언급한 문제가 자동으로 해결되고 커뮤니티를 "분할"할 위험이 제거될 것이라고 확신하지 않습니다. BDFL 모델보다 개선될 수 는 있지만 안정성 자체를 보장하는 것은 아닙니다. 오픈 소스의 역사, 그리고 일반적으로 인류의 역사는 불일치와 갈등으로 파괴된 민주주의 사회의 많은 예를 제공합니다.

@theckman , @ngrilly 가 예의를 갖추려고 노력하는 동안 구체적으로 말씀드리겠습니다. vgo 제안이 승인될 준비가 되지 않은 기술적 문제가 있는 경우 최대한 빨리 여기로 알려주세요! 알려진 문제 중 일부가 적절하게 해결되지 않았다고 생각되면 저희에게 알려주십시오. 그런 경우가 없다면 누가 "제안을 받아들일 시간이다"라고 말할 것인가? 두 달 동안 논의할 시간이 있었습니다. 기술적으로 충분하지 않은 이유가 있다고 생각하시면 말씀해 주십시오.

아무 이유 없이 여기에 더 많은 정치를 추가하려는 것처럼 들립니다. 그러면 모든 것이 느려질 뿐입니다. 우리가 충분히 운이 좋고 다른 해를 끼치지 않는다면 말입니다. 그리고 이것에 대한 이유가 있다고 생각하더라도 - 이것은 이것을 논의하기에 적절한 장소가 아닙니다 - 대신 메일 목록에서 이 토론을 시작하십시오.

주제넘은 댓글 하나 더 죄송합니다 여러분!

@powerman 절름발이에 죄송하고 이전 의견을 인용하십시오.

현재로서는 vgo 내에서 기술적 결정과 관련하여 깊은 이견이 있는 것처럼 느껴집니다. 내가 두려워하는 것은 생태계와 커뮤니티를 분열시킬 것입니다. 이를 염두에 두고 경쟁 제안이 완료되고 스포트라이트를 받을 때까지 시간을 조금 더 허용해야 한다고 생각합니다.

나는 대안적인 제안이 오고 있다는 것을 알고 있고, 나의 요구는 그들이 시간이 될 때까지 키보시가 이것을 받아들이도록 하는 것이었다. 한동안 의존성 관리를 하지 않았기 때문에 다른 제안에 대한 마무리 작업을 허용하면서 단기 체류를 요구하는 것은 무리가 아니라고 생각합니다.

형식이 약간 제한되어 있기 때문에 이 문제에서 이를 잘 표현하는 것이 쉬운지 잘 모르겠습니다. 그래도 기본적으로 WIP 제안의 일부를 복제할 것이기 때문에 주저할 것입니다. 나는 아이디어를 파편화하거나 저자의 천둥을 훔치고 싶지 않습니다.

그러나 이러한 제안이 진행 중이고 누가 작업하고 있는지 알면 준비가 완료되었다는 선언이 이러한 경쟁적인 의견을 억제하려는 적극적인 시도처럼 느껴졌습니다. 나는 Gopher로서 수년 동안 관찰한 패턴 때문에 이러한 우려를 제기해야 한다고 느꼈습니다. 나는 진정으로 언어, 생태계 및 커뮤니티가 성공하기를 원하며 이는 오로지 그 목표를 염두에 두고 제기되고 있습니다.

편집: 명확히 하자면 단기 체류는 2개월 또는 그와 유사한 것을 의미하지 않습니다. 나는 몇 주를 의미합니다.

@ngrilly 죄송합니다. 귀하의 의견을 무시하려는 것은 아닙니다. 나는 이전에 그것을 다룰 계획이었지만, 결국 내가 원하는 것보다 더 장황했다.

두 가지 문제가 있다고 생각합니다. 이러한 결정이 어떻게 내려지는지에 대해 다른 포럼에서 논의해야 할 사항이 있다고 생각하기 때문에 이에 대한 컨텍스트를 추가했지만, 다른 제안이 승인될 때까지 이 제안의 수락을 일시적으로 중단하는 데 집중하고 싶습니다. 공개의 기회를 가졌습니다.

나는 대안적인 제안이 오고 있다는 것을 알고 있고, 나의 요구는 그들이 시간이 될 때까지 키보시가 이것을 받아들이도록 하는 것이었다. ... [K]그 제안이 진행 중이고 누가 작업 중인지 알면 준비 선언이 이러한 경쟁 의견을 억압하려는 적극적인 시도처럼 느껴졌습니다.

그렇지 않았다고 장담합니다. 저는 여기서 타임라인에 대해 꽤 명확하게 알고 있습니다. 2월 중순의 내 첫 번째 게시물에 따르면 vgo 제안을 Go 1.11에 통합하는 것이 목표입니다. 개발 동결 접근. 진행 중인 다른 제안이나 누가 작업하고 있는지에 대해서는 아는 바가 없습니다. 그것은 나에게 새로운 소식이다. 사람들이 이 제안에 참여하거나 반대 제안을 하고 싶다면 이 제안이 공개된 지 한 달 반이 지나서 조금 늦어지고 있습니다.

분명히 말씀드리자면 Golang Weekly와 다른 사람들이 보고한 내용에도 불구하고 저는 제안을 수락한 것으로 표시하지 않았습니다. 나는 단지 그렇게 할 때라고 생각한다고 말했다. 즉, Proposal-Accepted 레이블을 적용하지 않았습니다. 바로 그렇게 하는 것에 대한 일반적인 합의가 있는지 먼저 확인하고 싶었기 때문입니다. 그리고 일반적인 합의는 적어도 https://github.com/golang/go/issues/24301#issuecomment -384349642의 이모티콘 카운터뿐만 아니라 전반적인 토론에서 판단할 때 수용에 찬성하는 것 같습니다.

대체 제안이 오는 것으로 알고 있습니다.

@theckman , 이와 같은 사실을 알고 계시다면 아마 당신만 알고 계실 것입니다. 지금까지 이 문제를 제기하는 사람을 본 적이 없습니다. Go 1.11에서 이것을 시도하고 싶다는 Russ의 진술은 처음부터 매우 분명했기 때문에 누군가가 대안 제안을 하고 있다면 약 2개월의 시간이 주어졌습니다.

또한 바둑팀이 섣불리 결정을 내리지 않는 좋은 실적을 갖고 있다는 점, 그리고 마지막 순간에 바둑 1.8이 옳지 않아 앨리어스를 어떻게 빼냈는지를 보면 받아들일 수 있다고 생각한다. 그 당시에 해야 할 일을 하려면 최소한 그들 자신의 실험/솔루션을 구축할 수 있도록 하는 예의를 주어야 합니다.

결국 이 제안은 사용되는 종속성 버전을 선택하는 방법에 대한 알고리즘 그 이상을 제공합니다. 누군가가 그것을 개선할 방법을 알아내면 두 가지 옵션이 있습니다. 일반 CL 프로세스를 통해 제출하거나 자신의 도구를 빌드하고 커뮤니티에서 사용하도록 선택하는 경우입니다. Go 팀은 여전히 ​​imho 도구의 자체 버전을 제공할 수 있으므로 이것이 닫힌 문제가 있다고 보지 않습니다.

그러나 지금까지의 분열 행동의 대부분은 바둑팀이 아닌 커뮤니티에서 이루어졌다는 점을 염두에 두시기 바랍니다. Go Team에게 도구를 빌드할 기회를 주고 실행 가능한 경우 평가한 다음, 얼마나 나쁜지에 대해 쓰기보다 개선하고 앞으로 나아갈 방법에 대한 논의를 테이블에 가져오도록 합시다.

이것을 다른 종류의 경험 보고서의 일부로 고려하십시오. 내가 Alias ​​제안에 대해 _매우_ 강력한 반대자였을 때 그 제안을 이해하고 현재 실행 중인 것을 보기 위한 보고서입니다.

편집: 원본 메시지에는 record of *not* making decisions on a whim 가 텍스트여야 하는 매우 불행한 누락이 있었습니다. 불행히도 "not" 부분이 누락되었습니다. 죄송합니다.

제안서에 대한 근본적인 우려 사항을 자세히 기록했습니다. 한 번에 소개할 수 있도록 이 글을 마치려고 노력했습니다. 이것은 복잡하고 미묘한 영역이므로 이러한 문제는 전체적으로 다루어야 합니다. 그러나 삶과 직장이 그것을 어렵게 만들었습니다.

내가 Slack에서 이 글을 언급하고 @rsc 와 직접 논의한 부분을 언급했지만 지금까지는 여기에 대해 언급하지 않기로 결정했습니다. 내가 완전히 발표할 준비가 되기 전에 이 글을 광고하는 것은 끔찍하게 건설적이지 않을 것 같았습니다. 그러나 언급한 바와 같이 두 달이 지났으므로 다음 주에 시리즈의 시작을 알리기 위해 큰 노력을 기울일 것입니다.

(편집: 이것은 @theckman 이 언급한 "대안"입니다)

@sdboyer 여러 가지 우려 사항이 있다고 언급하셨습니다. 적어도 지금 당장 그들의 목록을 공개해 주시겠습니까?
저는 의존성 지옥을 다른 수준(chef, go, npm, 작곡가)으로 끌어들이는 여러 시스템으로 작업하고 있으며 경험상 이 제안은 go와 관련하여 모든 시스템에 대한 솔루션입니다.

@theckman , @sdboyer 의 피드백만 언급한 것인지 확인할 수 있습니까? 그건 비밀이 아니야. Sam은 말 그대로 vgo가 출시된 첫날에 대해 언급했습니다("내 문제에 대해 더 자세한 문서를 작성 중입니다" - https://sdboyer.io/blog/vgo-and-dep/). 그러나 그것은 제안이 아니라 피드백이며 복수형 "기타 제안"을 여러 번 언급했습니다. 더 알고 있는 것이 있습니까?

go/types API 사용자를 위한 vgo의 의미는 무엇입니까? go/types 지원의 현재 상태는 무엇입니까?

vgo-aware go/types.Importer 구현을 추가하기 위해 PR mdempsky/gocode#26을 받았지만 이것이 필요한지/왜 필요한지 확실하지 않습니다.

필요하다고 가정하면 go/types 기반 도구가 각각 이 지원을 다시 구현할 필요가 없도록 표준 vgo-aware go/types.Importer를 다른 위치(예: x/vgo 또는 x/tools repo)에 추가할 수 있습니까? ?

나는 실제로 vgo 세부 사항을 따르지 않았으므로 이것이 단순히 "영향 없음"일 수도 있지만 위의 go/types에 대한 언급은 없습니다. "vgo go/types golang"에 대한 Google 검색도 유사하게 유용하지 않습니다.

감사 해요.

@mdempsky , 계획은 vgo-aware(그리고 그 문제에 대해 캐시 인식 빌드) 패키지 로더, 아마도 golang.org/x/tools/go/packages를 갖는 것이지만 아직 존재하지 않습니다. 사람들은 버려야 할 코드를 작성하는 대신 해당 패키지를 기다려야 합니다. PR을 병합하지 마십시오. 나는 그것에 대해 논평했다.

@mdempsky 는 https://github.com/mdempsky/gocode/pull/26 에서 답장을 하려고 했지만 일단 여기에서 답장을 드리겠습니다.

https://github.com/mdempsky/gocode/pull/26 은 완전히 폐기됩니다. vgo 에 대해 현재 포기된 CL을 사용하는 개념 증명일 뿐입니다.

방금 @rsc 회신을 보았으므로 https://github.com/golang/go/issues/14120#issuecomment -383994980에서 진행 중인 토론도 있음을 간단히 지적하겠습니다.

요약: 버전에 대한 몇 년의 경험 후, 마지막 최선의 시도는 매우 복잡한 알고리즘인 sat solver였습니다. 그러나 입력 데이터를 약간 수정하면 NP-완전 결정 문제가 관리할 수 있을 뿐만 아니라 매우 빨라집니다.

NPM을 사용한 경험이 많은 Go의 소규모 팀 사용자로서 저는 vgo 제안을 매우 좋아합니다. FWIW, 저는 vgo가 go 적절하게 구현되기를 기대하고 있으며 더 빨리 내 팀과 저에게 더 좋습니다.

내가 특별한 사람이 아니라, 작은 팀 문제에 대한 토론을 본 이후로 내가 차임을 할 것이라고 생각했습니다.

여기 내 리뷰가 있습니다.

표면적으로는 제안 문서의 마지막 개정판 의 _Proposal_ 섹션이 아주 구체적이지는 않더라도 괜찮아 보입니다(예: Subversion 이 어느 정도 지원될 수 있는지 불분명). 한 가지 예외는 "하나의 제한된 사용을 제외하고 공급업체 디렉토리의 사용을 허용하지 않음"은 공급업체 디렉토리가 모듈이 아닌 패키지에서 전혀 지원되지 않는다고 말하는 것 같습니다. 그렇습니까?

반면에 제안은 현재 go get 의 다양한 이점을 훼손하는 특정 설계 및 구현 결정을 암시합니다. 손실은 수용할 수 있고 일부는 피할 수 있지만 vgo get 가 go get 를 대체하는 경우 설계 고려 사항으로 다루어야 하고 논의해야 합니다. 그렇지 않으면 적절한 대체품이 아니며 vgo 가 go 로 병합되지 않거나 go get 가 타사 도구로 부활해야 합니다.

_Implementation_ 섹션은 다음과 같이 말합니다. GOPATH에서의 작업 지원은 무기한 계속될 것입니다.” 이것은 번거롭습니다. 첫째, 몇 년 동안 업데이트되지 않은 좋은 프로젝트가 많이 있습니다. Go 1 호환성 약속 덕분에 여전히 작동하지만 많은 사람들이 go.mod 파일을 추가하지 않을 것입니다. 둘째, 종속성이 없는 프로젝트의 개발자나 버전에 신경 쓰지 않는 개발자는 모듈 파일을 추가하거나 새로운 go get 생태계에서 기권하도록 합니다. 이것을 원하는 것이 정당할 수 있지만 그 이유를 설명해 주십시오. (나에게는 불필요하게 번거로운 것 같습니다. 차라리 이전 go get 포크를 사용하고 싶습니다. 다른 언어의 패키지 관리자가 훨씬 더 번거롭다는 데 동의합니다. vgo 그들보다 낫지 만 현재 go get 보다 내 사용 사례를 더 잘 처리하지 못합니다. 가끔 govendor 의 도움을 받습니다.

vgo 대 go에 대한 나의 주요 관심사는 지원하는 워크플로입니다. vgo-intro 포스트에서 표현한 적이 있습니다. 이것은 제안의 _호환성_ 섹션에 광범위하게 속하거나 범위를 벗어날 수 있지만 여기에서 제기된 다른 질문 및 문제와 일치합니다.

일부 이후 릴리스에서는 버전이 지정되지 않은 이전 go get에 대한 지원을 제거할 예정입니다.

제안의 다른 측면은 괜찮게 들리지만 이것은 불행한 것입니다. (만약 내가 go 도구 체인에 버전 관리를 통합하는 것과 계속해서 버전 제어 도구로 작업하는 것 사이에서 선택해야 한다면 나는 후자를 선택할 것입니다.) vgo의 장점은 재현 가능한 빌드를 용이하게 하고 프로젝트 중단을 지연한다는 것입니다. 프로젝트 작성자(go.mod 파일 포함)가 직면할 때까지 호환되지 않는 업데이트로 인해; 그러나 go get의 장점은 다중 리포지토리 세계에 단일 리포지토리의 이점을 제공한다는 것입니다. 종속성의 완전한 복제로 인해 자신의 프로젝트와 마찬가지로 쉽게 작업할 수 있습니다(내역 검사, 편집, 변경 사항 비교, 모든 것에 대한 정의로 가서 그것을 비난), 협업을 촉진하고(간단히 변경 사항을 푸시하고 제안함) 일반적으로 항상 세계의 현재 상태는 각 프로젝트의 끝 부분이며 모든 것이 있다는 관점을 부과합니다. 다른 것은 역사다. 이 독특한 접근 방식(실제 모노리포지터리 외부)은 나쁜 것보다 좋은 것을 더 많이 한 Go 생태계의 독특한 장점이며 버려서는 안 된다고 생각합니다.

제안의 더 미묘한 부정적인 결과는 버전 관리를 치료 불가능하고 상속 가능하게 만든다는 것입니다. 프로젝트가 버전에 태그를 지정하면 새 버전에 태그를 지정하지 않고는 향후 변경 사항이 사용자에게 도달할 것이라고 기대할 수 없습니다. 원래 작성자가 계속 태그를 지정하기로 결정한 경우에도 포크 작성자는 이제 그들에게도 태그를 지정하거나(소스 프로젝트가 여전히 활성 상태인 경우 특히 어색함) 이전 태그를 삭제해야 합니다.

전반적으로 종속성 관리에 대한 현재 Go 접근 방식이 버전 관리보다 전반적으로 우수하다는 점을 강조하고 싶습니다. 모든 커밋이 표시될 것으로 기대하는 현대적이고 역동적이며 협업적인 오픈 소스에 더 잘 부합하며 릴리스 소스만 게시하는 것(또는 거대한 비기술적 커밋에서 "내부 변경 통합")만으로는 충분하지 않습니다(가시성, 협업이 심각하게 감소하기 때문에). 그리고 역동성). 모노리포지토리와 현재 Go 생태계에서 대부분의 프로젝트에 버전이 필요하지 않다는 것을 알 수 있습니다. 물론 이 접근 방식은 궁극은 아니며 단점이 있으며 버전이 있는 프로젝트도 지원하는 것이 중요하지만 버전이 없는 사람에게 피해를 입히면 안 됩니다.

요약하면 현재 go get (보조 도구 포함, 예: godef )는 다음과 같은 기능을 갖춘 워크플로를 지원합니다.

• 종속성의 편집 가능한 소스 코드
• VCS에서 종속성의 소스 코드
• 종속성의 최신 개정판

종속성의 소스 코드는 계속 편집할 수 있다고 가정할 수 있습니다. 예를 들어 godef 는 _쓰기 방지가 되지 않고 _빌드 중에 사용되는 _파일_에 연결됩니다. 그러나 vgo 은 다른 두 점에서 어긋납니다. 두 번째 요점과 관련하여 #24915는 VCS 도구에 대한 지원을 연장했지만 여전히 중단하려는 목표를 선언합니다. 워크플로는 종속성이 VCS에서 체크아웃될 뿐만 아니라 체크아웃이 개발자에게 유용해야 하며(예: .git 가 제거된 git 체크아웃이 아닌 얕은 git 체크아웃이 아님) 빌드 중에 사용되어야 합니다. 하지만 vgo 는 이 요구 사항을 충족하지 않을 수 있습니다. 세 번째 요점에 관해서는 vgo-intro 주석에서 그 가치를 정당화했지만 vgo 는 그것을 완전히 포기한 것 같습니다.

Go 버전 관리 도구는 현재 워크플로에 대한 지원을 중단할 필요가 없으며 Go 에코시스템에서 작업하는 고유한 이점을 유지하고 go get 에 대한 적절한 대체가 되기 위해 중단해서는 안 됩니다. vgo 의 디자인은 이것을 어렵게 만들지만 분명히 불가능하지는 않습니다. 반면에 제안서의 _Proposal_ 섹션은 현재 워크플로와 거의 호환되는 것 같습니다. 세 번째 요점(최신 개정판 확인)을 지원하는 데 도입되는 유일한 문제는 큰 문제입니다. 모듈 ≥v2.0.0에 대해 master 에서 확인할 수 있는지 여부를 결정하기 어렵게 만든다는 것입니다. master 이 다른 주요 버전에 있으므로 지정된 대로 체크아웃해야 하는지 여부. 이것은 모든 것이 기본적으로 master 에서 체크 아웃되고 gopkg.in의 항목은 일치하는 태그 또는 분기에서 체크 아웃되기 때문에 gopkg.in 이 있는 현재 go get 에 대한 도전이 아닙니다. 그러나 vgo 는 이 구분을 흐리게 하고 gopkg.in 모델을 모든 패키지에 퍼뜨립니다. (게다가 분기 일치를 중지합니다.) 사실상 확실하게 말할 수 없고 지정된 주 버전의 최신 개정판을 얻는 방법을 추측하는 것이 필요합니다.

놓쳤을 수도 있지만 이 시나리오에서 vgo는 어떻게 작동할까요?

• lib X에 따라 서비스 A와 서비스 B에서 모두 작업합니다(저도 작업 중).
• lib X의 주요 변경 사항이 필요합니다.

현재의 방법으로 나는 변경을 수행하고 서비스 A와 서비스 B를 컴파일하고 lib X에 대한 내 $GOPATH에 있는 모든 것을 선택하고 수정한 다음 주요 semver 범프로 lib X를 푸시한 다음 두 서비스를 모두 푸시합니다. A와 B는 Gopkg.toml 에서 lib X의 새로운 전공을 사용하라고 말합니다.

이제 vgo가 인수되면 내 서비스의 go build 가 github에서 존재하지 않는 새 버전의 lib X를 찾으려고 시도하고 모든 종류의 문제를 예측할 수 있습니다.

그래서, 내가 명백한 것을 놓치고 있습니까?

이러한 유형의 항목에 대해 replace 지시문을 사용할 수 있습니다.

2018년 4월 30일 월요일, 12:15 Antoine [email protected] 에서 다음과 같이 썼습니다.

놓쳤을 수도 있지만 이 시나리오에서 vgo는 어떻게 작동할까요?

• 나는 lib X에 따라 서비스 A와 서비스 B에서 모두 작업합니다.
  도 작업)
• lib X의 주요 변경 사항이 필요합니다.

현재의 방법으로 변경 작업을 수행하고 서비스 A를 컴파일하고
서비스 B, 그들은 lib X에 대한 내 $GOPATH에 있는 것을 선택하고, 나는 물건을 고칩니다.
그런 다음 주요 semver 범프로 lib X를 푸시한 다음 서비스 A와 B를 모두 푸시합니다.
Gopkg.toml에서 lib X의 새로운 전공을 사용하라고 말합니다.

이제 vgo가 인수되면 내 서비스를 기반으로 이동하여 비를 찾으려고 시도합니다.
github에서 lib X의 기존 새 버전과 모든 종류의
근심거리.

그래서, 내가 명백한 것을 놓치고 있습니까?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/24301#issuecomment-385499702 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAuFsfnD8_kbUj8fSXvGgeN77ki6KYM6ks5tt2LLgaJpZM4Sg3bp
.

@kardianos 예, 하지만 여전히 시도하기 위해 lib 변경 사항을 푸시해야 한다는 의미인가요?

편집: 대체 경로를 사용할 수 있는 것 같습니다(https://github.com/golang/go/issues/24110). 이는 좋은 것입니다. 그러나 나는 이것이 여러 번 저지르게 될 것이라고 예측할 수도 있습니다.

go.mod.replace 또는 이와 유사한 것과 같은 추가 파일을 생성하여 개발 환경에서 재정의를 정의하고 gitignore할 수 있도록 할 계획이 있습니까?

@primalmotion 잘못된 커밋을 방지하려면 아마도 git hook을 사용해야 할 것입니다.

그러나 정답은 너무 자주 이 작업을 수행하지 않는 것입니다(로컬 경로로 교체). 라이브러리가 너무 밀접하게 결합되어 있으면 별도의 저장소에 있으면 안 됩니다(따라서 느슨하게 결합된 척). 일반적으로 이러한 서비스의 현재 구현을 고려하지 않고 해당 라이브러리를 수정, 테스트 및 릴리스할 수 있어야 합니다. 특히 vgo를 사용하면 두 서비스 모두 이전 lib 버전(이전에 사용했던)을 계속 사용하여 해당 lib의 최신 버전으로 수동 업데이트할 때까지 계속 사용할 수 있습니다. 1년에 한 번 로컬 경로에 대한 교체를 가끔 커밋하는 경우 - 큰 문제는 아니지만 CI가 이를 알아차리고 몇 분 안에 수정할 수 있도록 도와줍니다.

go.mod.replace 버전이 없는 @primalmotion 은 재현할 수 없는 프로젝트를 커밋할 수 있습니다. 대신 go.mod 의 교체를 사용하면 현재 사용하고 테스트하는 것을 정확히 커밋할 수 있습니다.
교체로 커밋하는 것은 실수일 수 있지만 이를 인지하고 수정할 수 있습니다.
또는 자발적일 수 있습니다. 저는 하위 모듈로 수행합니다. 프로젝트와 라이브러리를 함께 작업할 때 괜찮고 하위 모듈을 커밋하면 재현할 수 있습니다. 저는 파이썬에서 자주 했고 Go에서는 놓쳤습니다. vgo를 사용하여 다시 그렇게 작업할 수 있어 기쁩니다. _(나의 나쁜 영어로 해결되기를 바랍니다, 죄송합니다)._

음, 문제는 우리가 관심을 갖기로 결정할 때까지(즉, 릴리스를 준비할 때까지) 재현 가능한 빌드에 대해 관심을 갖지 않는다는 것입니다. 우리는 라이브러리 업데이트가 단지 체크아웃, 재구축, 테스트 실행인 매우 민첩한 개발 환경을 가지고 있습니다. 우리는 우리 서비스의 마스터 브랜치에서 Gopkg.lock을 커밋하지 않고 외부 라이브러리에 대한 고정 버전과 주요 제약 조건이 있는 toml만 커밋합니다. 릴리스 브랜치를 생성한 다음 Gopkg.lock을 커밋한 다음에만 재현 가능한 빌드를 갖게 됩니다(이 작업은 ci에서 수행).

Vgo는 기본적으로 우리가 수년 동안 구축한 모든 워크플로를 깨뜨립니다. 이제 라이브러리에서 약간의 인쇄 디버깅과 같은 멍청한 것을 시도하거나(우리 모두가 이것을 하기 때문에 거짓말을 하지 않습니다. :)) 또는 약간의 최적화를 시도하려면 수십 개의 서비스를 살펴보고 replace 를 추가해야 합니다.

vgo가 우리에게 도움이 될 수 있는 것:

• 내가 언급한 재정의 시스템
• 전혀 사용하지 않고 개발을 위해 좋은 이전 GOPATH로 폴백하는 방법입니다.

그리고 우리는 그것이 굉장하기 때문에 그것이 우리를 위해 작동하기를 정말로 원합니다.

go 1.11에서 테스트할 것이 있습니까(지금은 정지 상태입니다) 또는 go 1.12에서 테스트할 수 있습니까?
이미 실험용으로 표시되어 있습니다. 그리고 실제 개발에서 더 많은 사람들이 테스트할수록 더 가치 있는 피드백이 될 것이라고 생각합니다.

버전이 지정된 패키지와 관련된 문제에 대해 읽었습니다. 하나의 간단한 시나리오의 경우 foo-plist 라는 plist 구문 분석에 dep를 사용하는 라이브러리를 작성하는 경우입니다. 구문 분석의 결과로 해당 plist 라이브러리는 자체적으로 특정 유형을 노출합니다. 이제 라이브러리가 v2로 업그레이드되고 해당 plist 유형의 개체를 반환하는 경우 내 라이브러리가 강제로 v2로 업그레이드됩니다.

예를 들어 내 라이브러리가 이 제안의 인상 하에 해당 plist 라이브러리의 v1 및 v2를 모두 지원하도록 하려면 이 문제를 해결하기가 상당히 어려운 것 같습니다.

예를 들어 npm에서 내 라이브러리는 >=1.0.0|>=2.0.0 라고 말하는 피어 종속성을 간단히 지정할 수 있으며 사용할 plist 버전을 결정하는 것은 라이브러리 사용자에게 달려 있습니다. 따라서 내 라이브러리 foo-plist 의 사용자가 plist 에 의존하는 다른 라이브러리도 사용하는 경우 두 라이브러리 모두 plist의 v1 및 v2에 만족하면 사용자는 어느 라이브러리를 선택할지 선택할 수 있습니다. 실제로 수입합니다. 더 중요한 것은 두 라이브러리 모두 plist 유형을 내보내면 해당 유형이 실제로 호환된다는 것입니다.

그들이 다른 가져오기 경로가 되면 이를 지원할 방법이 없다고 생각합니다.

@itsnotvalid foo-plist.2는 foo-plist를 가져오고 유형 별칭을 사용하여 해당 유형을 다시 내보낼 수 있습니다. 이 기술에 대한 좋은 설명은 https://github.com/dtolnay/semver-trick 에서 찾을 수 있습니다.

Aram은 여기 에서 이전 릴리스 분기(또는 디렉토리)에 대한 변경 사항을 백포팅하는 것이 어렵다는 점을 지적했습니다. 동일한 모듈 내의 소스에 대한 "자체" 참조에는 가져오기 경로의 버전도 포함되기 때문에 패치를 완전히 가져오지 않거나 실수로 버전 간 가져오기를 도입할 수 있습니다.

생각?

분명히 말씀드리자면, 저는 가져오기 경로의 버전을 사용하는 모듈 간 가져오기에 전적으로 익숙합니다. 나는 Russ의 주장이 매우 설득력이 있다고 생각합니다. 모듈 내 가져오기에 대해서는 명확하지 않습니다. 빌드에서 주어진 패키지에 대해 단일 가져오기 경로를 갖는 목표를 이해하지만(교차 모듈로 가져오든 자체 모듈 내에서 가져오든 상관없이), 선택해야 한다면 이 속성을 유지하는 것보다 아람의 문제. (또한 빌드 시스템이 최상위 모듈을 빌드할 때 모드 파일에서 버전을 주입하고 모듈 종속성을 다운로드한 후 말 그대로 소스에 주입할 수 있다고 상상합니다)

@rsc 앞으로 나아갈 가능성이 있습니까? 나는 이것을 막는 중요한 것을 보지 못합니다.

내가 이것에 대해 참을성이 없는 것 같다면 유감이지만 vgo 지원을 위해 작업하는 도구가 점점 더 많아지고 이를 지연할수록 도구 관리자인 우리에게 이 문제를 왔다 갔다 하는 것이 더 엉망이 될 것입니다. .

@sdboyer 는 이번 주에 자신의 글을 게시할 계획 입니다. 나는 그들을 기다리는 것이 공평하다고 말하고 싶습니다.

모듈, 프록시 지원, 버전 관리 등과 같은 항목도 포함하는 전체 제안을 차단하는 원인이 되지 않아야 하는 종속성 버전을 선택하기 위한 해결 알고리즘이 있다고 생각합니다.

그리고 나중에 이러한 종속성을 다운로드하기 위한 알고리즘을 개선/변경하기로 결정하면 다른 영향 없이 그렇게 할 수 있습니다.

나는 @dlsniper 에 동의합니다. 우리는 이미 동결 상태에 있으며 vgo 디자인이 도입된 지 거의 3개월이 지났습니다. 1.11에 대한 작업이 더 지연되면 1.12로 다시 밀려날까 걱정입니다.

시리즈가 될 첫 번째 게시물이 드디어 공개되었습니다 . 게시하는 데 시간이 너무 오래 걸리고 시리즈가 종료되기까지 더 오래 걸릴 것이라는 점에 대해 사과드립니다. 그러나 첫 번째 게시물은 전체 시리즈에서 다루려는 주제에 대한 광범위한 개요를 제공하므로 사람들은 최소한 범위를 이해할 수 있어야 합니다.

간단히 말해서, vgo에는 훌륭한 것들이 많이 있으며, 그 중 많은 부분이 커뮤니티로서 오랫동안 원해왔습니다. 그러나 나는 MVS가 목적에 부적합하며 프로덕션에 적합하지 않다고 생각합니다. 우리가 원하는 이러한 많은 것들이 MVS를 둘러싸고 있다는 것은 유감스러운 일입니다. 특히 그 중 극히 일부만 MVS에 국한된 경우에는 더욱 그렇습니다. 저는 블로그 시리즈 전체에서 비교 목적으로 참조되는 대체 접근 방식을 연구 중이며 최종 게시물에서 설명할 예정입니다.

내가 작업하고 있는 대체 핵심 알고리즘은 go.mod 로 마이그레이션하는 것이 매우 간단하므로 문제가 있을 것으로 예상하지 않습니다. 종속성의 전이적 폐쇄를 포함하는 별도의 잠금 파일이 추가되었으며 빌드 목록 알고리즘이 아니라 컴파일러가 읽는 내용이 됩니다. (잠금 파일에 대한 다른 이유도 있지만 포스트 5에 있을 예정입니다.) 최소한, 그것은 우리에게 탈출 밸브를 제공합니다.

그러나 우리가 MVS가 괜찮다고 하면 임시방편으로라도 들어가 관성의 이점을 얻습니다. 그 시점에서 우리는 그것이 @rsc 에 부적절하다는 것을 증명해야 하고(사실 그는 그것이 병합되기 전에 이미 표준으로 설정했지만) 이것이 현재 go get 에 대한 진정한 진술 이라고 믿습니다.

오늘날 많은 프로그래머는 대부분 버전 관리에 주의를 기울이지 않으며 모든 것이 잘 작동합니다.

위의 모든 사항을 감안할 때 지금 진행하면 "제네릭, 2라운드"가 생성될 것입니다. 단, 이번에는 기계가 아니라 서로 상호 작용하는 방식을 제어하는 ​​규칙에 관한 것입니다.

그러나 우리가 MVS가 괜찮다고 하면 임시방편으로라도 들어가 관성의 이점을 얻습니다.

현재 dep에는 관성의 이점이 있습니다(둘 다 다른 언어의 버전 관리자와 동일한 전제에 구축되고 광범위한 커뮤니티 지원으로 더 오래 존재함). 적어도 나에게는 vgo 제안이 좋은 주장에 의해 뒷받침되는 좋은 디자인이 됨으로써 이 관성을 극복할 수 있었습니다.

개인적으로 Go의 버전 관리가 지연되더라도 상관하지 않습니다. 빠른 것보다 올바른 일을 하는 데 찬성합니다. 그러나 적어도 현재로서는 vgo가 여전히 나에게 올바른 솔루션으로 보입니다(그리고 AIUI 커뮤니티의 많은 사람들은 이것을 긴급한 문제로 인식합니다).

@mvdan 이 변경은 영향이 없는 것이 아닙니다. 우리 모두는 이것을 원하지만, 특히 그러한 의심을 제기한 사람이 문제에 대해 많은 생각을 분명히 했을 때 의심을 잠재우기 위해 시간을 더 투자하는 것이 현명하다고 생각합니다.

1.11 vgo 미리보기를 얻는 데 미치는 영향과 동결에 대한 언급을 계속 듣습니다. 1.11 에 통합될지 여부에 대한 현시점의 공식 라인은 무엇입니까? 이 문제는 잠재적인 영향을 고려할 때 놀라울 정도로 조용한 것 같습니다.

@sdboyer MVS에 대한 귀하의 입장을 공식적으로 _just_ 공식적으로만 밝혔을 때 이것이 1.11 에 병합되어야 하는지 여부에 대한 귀하의 입장은 무엇입니까?

이것이 1.11 가 되지 않으면 2019년 2월 1.12 이 될 때까지 공식적으로 미리 볼 수 없으며 8월에 최소 1.13 까지 공식적으로 출시됩니다. 2019. 이것은 @rsc 가 처음 논의를 시작한 지 18개월 후 가장 빠른 잠재적 릴리스입니다. 물론 우리는 이것을 불필요하게 서두르면 안 됩니다. 그러나 위에서 @Merovius 가 언급했듯이 나를 포함한 많은 사람들은 종속성 관리에 대한 공식적인 대응을 "긴급" 문제로 간주합니다. 18개월을 기다리는 것은 너무 과한 것 같습니다.

확실히 dep 가 공식적인 응답이 될 것 같았고 우리는 저장소를 변환했습니다(결과에 만족했습니다). 이 제안은 장기적으로 dep 를 효과적으로 사용하지 않지만 vgo 통합을 시작할 공식적인 방법이 없기 때문에(적어도 #25069가 병합될 때까지) 유통 기한이 매우 제한된 도구( dep )를 사용하십시오.

FWIW, 저는 1.11 vgo 를 통합하고 1.11 에 #25069를 포함하여 (그리고 1.9 에 대한 패치 릴리스로) 이를 진행해야 한다고 절대 생각합니다. 1.10 출시 시 1.11 ).

나는 솔직히 MVS와 @sdboyer가 그것에 대해 우려하는 모든 의미를 골똘히 생각하지 않습니다. 그러나 이 분야에서의 그의 경험을 고려할 때 이러한 우려는 진지하게 고려할 가치가 있다고 생각합니다. 즉, 그가 1.11 vgo 와 MVS를 통합하는 데 온보드라면 (그의 [아직 진화하고 있는] 제안이 [ 1.12 에 대해] 수락된다면 모듈이 손상되어서는 안 됩니다. 원래 MVS용으로 설계됨), 앞으로 나아가지 않을 이유가 없습니다.

또한 이 제안에 대해 @rsc 에게 감사드립니다. Go가 다른 도구의 접근 방식을 복사하지 않고 관용적으로 보이는 방식으로 이 문제를 해결하려고 한다는 점에 감사합니다. 종속성 관리가 결코 재미있지는 않지만, 이 제안을 통해 Go는 업계를 발전시키고 현재 최고로 간주되는 시스템을 도약할 수 있는 잠재력을 가지고 있는 것 같습니다.

$.02를 추가하기 위해 MVS는 종속성 관리를 위한 "아하" 순간이라고 생각합니다. 나는 사람들이 그것에 대해 많은 생각을 했음에 감사하지만 MVS가 이것이 필요한 곳이라고 확신합니다.

나는 특히 다른 사람들이 제기한 요점에 동의합니다. "자동 보안 수정"은 기껏해야 헛된 꿈이고 최악의 경우 엄청난 양의 웜입니다.

또한 @joshuarubin 과 함께합니다. 종속성 관리에 대한 공식적인 대응이 시급한 문제입니다. 다른 사람들은 우리가 지금 MVS로 나아갈 수 있고 나중에 필요한 경우 다른 솔루션으로 변경할 수 있다고 언급했습니다. 그것이 정말로 가능하다면 그것이 더 나은 방법이라고 생각합니다.

다음과 같은 방법으로 주요 버전을 가져오기 경로에서 분리할 것을 제안합니다. (저는 vgo-import 에서 추론을 설명했으며 거기에 명시된 vgo 성과를 저하시키지 않는다고 믿습니다.) 이것은 #25069에서 Go 1.9 및 1.10의 go build 가 다음을 배워야 한다는 아이디어에서 영감을 받았습니다. 가져오기 경로를 창의적으로 해석(버전 부분 삭제) 내 제안에서 old go build 는 변경되지 않지만 vgo 는 비슷한 트릭을 배웁니다.

구문적으로 유일한 변경 사항은 다음과 같습니다.

1. .go 파일에서 $ v2 import "repo/v2/pkg" 는 import "repo/v2/pkg" $로 유지되지만 그렇지 않으면 import "repo/pkg" 가 됩니다. 이것은 현재 go get 와의 호환성을 유지합니다.
2. go.mod 파일에서 v2 하위 디렉터리에 있으면 module "repo/v2" 가 동일하게 유지되지만 최상위 수준에 있으면 module "repo" 가 됩니다. (이것은 표준 가져오기 접두사입니다.)
3. go.mod 파일에서 require repo v2.3.4 as repo2 도 쓸 수 있습니다. 그런 다음 .go 파일에서 import "repo2/pkg" (또는 import "repo2/v2/pkg" v2 17$#$)를 사용합니다. 이것은 현재 go get 로 가져올 수 없습니다( require github.com/owner/project v2.3.4 as gopkg.in/owner/project.v2 와 같은 것을 사용하지 않는 한), 이것은 동일한 모듈에서 여러 주요 버전을 사용하고 종속성이 없는 경우에만 필요합니다. 어쨌든 현재 go get 에서 지원할 수 없는 하위 디렉토리에 주요 버전을 저장합니다.

기술적으로 이렇게 하면 go.mod 를 다음과 같이 쓸 수 있습니다.

require repo v1.0.0
require repo v1.1.1 as repo1
require repo v2.2.2 as repo2
require repo v2.3.3 as repo3

그러나 최소 버전 선택은 repo 및 repo1 모두 v1.1.1 및 repo2 및 repo3 의 저장소를 참조하도록 이 문제를 해결합니다. v2.3.3 . 이 앨리어싱을 허용해야 하는지 금지해야 하는지 모르겠습니다.

장점:

• 모듈 인식 코드는 현재 go get , v2.0.0 이전에도 호환됩니다. 따라서:
  
  
  
  • go get 모듈을 최소한으로 인식할 필요 없음(#25069)
  
  
  • v2.0.0 이전의 프로젝트는 모듈을 인식하지 않는 go get 와의 호환성을 깨뜨릴 필요가 없습니다.
  
  
• 프로젝트는 모듈 자체가 되기 전에 종속성이 모듈이 될 때까지 기다릴 필요가 없습니다. [1]
• 모듈을 인식하지 않는 프로젝트를 더 이상 사용하지 않거나 작성자가 새로운 모듈을 인식하지 못하는 프로젝트를 시작하는 것을 방해할 필요가 없습니다.
• 현재 go get 의 버전 없는 워크플로에 대한 지원을 유지하기가 더 쉽습니다( 여기 및 위에서 설명됨).

단점:

• 이미 작성된 go.mod 파일이 계속 작동한다는 약속을 지키는 것이 불편할 수 있습니다(새 모듈 파일의 이름이 go.mod 와 다르게 지정되지 않는 한).

양면성:

• 다른 모듈의 동일한 가져오기 경로는 다른 주요 버전을 참조할 수 있습니다.
  
  
  
  • 좋음: 이전 v2.0.0 및 주요 버전 변경 시 유지 관리가 더 쉽습니다.
  
  
  • 나쁜: go.mod 를 보지 않고 사용하는 주요 버전을 모릅니다.
  
  
• 모듈은 코드 내에서 사용할 임의의 가져오기 접두사를 정의할 수 있습니다.
  
  
  
  • 일부 사용자는 짧은 이름으로 모든 항목을 가져오도록 선택합니다(예: import "yaml" with require gopkg.in/yaml.v2 v2.2.1 as yaml ).
  
  

[1] 현재 vgo 는 모듈의 비모듈 전이 종속성이 v2.0.0 이후인 경우에만 비모듈 종속성을 적절하게 지원할 수 있습니다. 그렇지 않으면 프로젝트는 v2.0.0 이후의 프로젝트에 간접적으로 의존하는 모든 종속성이 모듈이 될 때까지 기다려야 합니다.

https://github.com/rsc/corpus의 패키지에서 찾을 수 있었던 Gopkg.toml 파일을 분석하고 https://github.com/zeebo/dep-analysis 에 요약을 작성했습니다 . 거기에 있는 데이터에 따르면 vgo가 식별된 거의 모든 사용 사례를 처리할 수 없다는 증거가 많지 않은 것 같습니다.

나는 이것이 커뮤니티의 두려움을 줄이는 데 도움이 되고, 도구에 대한 실제 경험을 얻기 위해 추가 6개월이 있음을 기억하고 제안을 있는 그대로 진행해야 한다는 합의에 이르는 데 도움이 되기를 진심으로 바랍니다. 발생할 수 있는 문제를 해결하기 위해 필요한 모든 변경.

내가 당신을 인용하면 :

모든 제약 조건의 거의 절반은 실제로 제약 조건이 아닙니다. 마스터 분기를 가리킵니다.

이것은 아마도 마스터만 존재하기 때문일 것입니다. 태그가 없거나 "v2, v3과 같은 명명된 분기"가 있습니다. 그렇다면 선택의 여지가 없기 때문에 비교가 공정하지 않습니다!

@mvrhov "공정하지 않음"이 무엇을 의미하는지 잘 모르겠습니다. 저에게는 vgo와 dep가 그 경우를 잘 처리할 것 같습니다. 아니면 그 어떤 현실적인 대안도 그 경우를 잘 처리 해야 할 것입니다. 특히: 아직 출시된 버전이 없는 경우 vgo 세계에서는 v1.0/v0.x 태그만 지정할 수 있으며 가져오기 경로(vgo의 주요 특징)를 변경할 필요가 없습니다.

내가 말할 수 있는 한, 분석의 요점은 다양한 접근 방식으로 인해 발생하는 실제 고통을 평가하고 시도하는 것입니다. 나는 이 사건이 누군가에게 실제적인 고통을 가져다주는 방법을 알지 못합니다.

이 제안은 2개월 이상 활발한 토론을 통해 공개되었습니다. @rsc & @spf13 은 피드백 세션을 수행하고 커뮤니티에서 귀중한 의견을 수집하여 제안을 수정했습니다. @rsc 는 또한 추가 피드백을 얻기 위해 @sdboyer 와 매주 회의를 진행했습니다. 제안에 대한 귀중한 피드백이 제공되어 추가 수정이 이루어졌습니다. 점점 더 이 피드백은 제안보다는 수반되는 구현에 대한 것입니다. 상당한 검토 후에 우리는 이 제안을 수락하고 Go의 광범위한 도구 구현 생태계가 중요한 조정을 시작하여 사용자 기반이 가능한 최고의 경험을 할 수 있도록 할 때라고 생각합니다.

우리가 이야기해야 한다고 생각하는 이 제안에 대해 두 가지 반대가 있었습니다.

1. 이 제안은 사람들이 라이브러리 사용 및 배포에 관한 관행을 일부 변경하도록 요구할 것입니다.
2. 제안은 비호환성과 관련하여 발생할 수 있는 모든 가능한 시나리오에 대한 기술 솔루션을 제공하지 못합니다.

이들은 관찰에 정확하지만 의도한 대로 작동합니다. 개발자가 gofmt 실행과 같은 Go의 다른 세부 사항에 적응한 것처럼 코드 작성자와 사용자는 라이브러리 사용 및 릴리스에 대한 일부 관행을 변경해야 합니다. 모범 사례를 바꾸는 것이 때로는 올바른 솔루션입니다. 마찬가지로 vgo는 비호환성과 관련된 모든 가능한 상황을 처리할 필요는 없습니다. Russ가 최근 Gophercon Singapore 연설에서 지적했듯이 비호환성에 대한 유일한 영구적인 해결책은 함께 협력하여 비호환성을 수정하고 Go 패키지 생태계를 유지하는 것입니다. vgo 또는 dep와 같은 도구의 임시 해결 방법은 개발자가 실제 문제를 해결할 시간을 줄 수 있을 만큼만 작동하면 되며 vgo는 이 작업을 충분히 수행합니다.

이 중요한 문제에 대해 보내주신 모든 피드백과 열정에 감사드립니다. 제안이 수락되었습니다.

— 바둑제안심의위원회

기록에 색을 더하기 위해 @sdboyer 와의 주간 회의를 지지로 간주해서는 안 됩니다. Sam은 최근 vgo에 대해 좋아하는 것과 함께 MVS의 문제에 대해 쓰기 시작했습니다 . 같이 오시는 분들에게 오해의 소지가 없도록 하기 위해 이렇게 덧붙입니다. 그의 의견을 원하시면 그의 글을 읽어보십시오. 내 생각은 그것들이 현재 의도된 접근 방식에 대해 상당한 정도의 불일치를 포함하고 있다는 것입니다.

@mattfarina FWIW, 나는 그 문장을 "(그가 개인적으로 표현한 대로) 그의 비판을 알고 있으며 우리의 의견을 바꾸지 않았습니다"라고 더 많이 읽었습니다. 그러나 그의 의견과 주장이 현재까지 공개되지 않은 것이 유감입니다.

접근 방식에 대한 근본적인 우려가 여전히 남아 있는 상태에서 제안을 수락하는 것은 무책임하게 느껴집니다. 작성자와 커뮤니티 도메인 전문가 @sdboyer 간의 합의는 제안이 수락된 것으로 간주되기 전에 도달해야 하는 합리적인 최소 기준인 것 같습니다.

@merovius 우리 중 몇몇은 공개적으로나 개인적으로 의견을 공유했습니다. 많은 사람들은 제기된 문제가 충분한 솔루션을 제공하기보다는 오히려 (때로는 무례하게) 무례하게 굴러갔다고 생각합니다. 저는 실용적인 문제를 공개적으로 공유하기 시작하여 우리가 해결하려고 노력할 수 있습니다. 예를 들어, 오늘은 실제 문제에 대한 세부 정보를 여기 에서 공유합니다. 재미있는 참고 사항은 이것이 수락된 것으로 표시되는 동시에 해커 뉴스의 첫 페이지에 있다는 것입니다.

@peterbourgon Go Dependency Management 설문조사에 참여하고 사람들이 필요로 하는 사항을 듣고 Glide에서 작업한 사람으로서 (단순한 의견이 아닌) 실질적인 문제를 보여줄 수 있습니다. 즉, 사용자의 욕구, 요구 및 기대를 해당 문제에 대한 솔루션에 맞출 수 있습니다. 내 우려는 vgo의 현재 경로에 대한 불일치입니다. 사람들이 의존성 관리를 수행하는 방식의 차이로 인해 충족되지 않은 요구 사항과 실용적인 문제가 있습니다.

내 우려를 완화하기 시작하는 쉬운 방법은 vgo가 Tim Hockins가 만족할 수 있도록 Kubernetes에서 작동하도록 하는 것입니다.

내 우려를 완화하기 시작하는 쉬운 방법은 vgo가 Tim Hockins가 만족할 수 있도록 Kubernetes에서 작동하도록 하는 것입니다.

오늘 vgo를 Kubernetes에서 작동하게 하시겠습니까? 아니면 향후 몇 년 동안 vgo를 Kubernetes에서 작동하게 하시겠습니까? 내가 이해하는 바에 따르면 vgo와 dep 사이의 근본적인 디자인 불일치 중 하나는 오늘날 존재하는 생태계와 함께 작업해야 하는지(dep의 가정) 또는 커뮤니티를 태그가 지정된 릴리스 및 호환성 유지로 전환할 수 있는지(vgo의 가정)입니다. .

따라서 Go 커뮤니티의 규범이 바뀔 때까지 vgo는 Kubernetes를 사용하는 다종속성에서 한동안 작동하지 않을 수 있습니다.

@mattfarina 물론입니다. 그러나 개인적으로 이것을 "스팀롤"로 그리는 것은 매우 실망스럽습니다. @sdboyer 는 몇 달 동안 공개 토론을 크게 기권했으며 여전히 그에 대한 실제적이고 구체적인 주장은 없습니다. 그에게는 나름의 이유가 있었고 그것은 정당했습니다. 그러나 합의에는 여전히 토론이 필요하며 적어도 공개 기록에 관한 한, 개인적으로 제기되고 명백하게 무시된 문제에 대해 개인적으로 인식하지 못합니다(아직 귀하의 게시물을 읽지는 않았지만).

내가 아는 한, 모든 토론은 비공개로 진행되었습니다. 그리고 어느 쪽이든 정보가 없다는 점을 감안할 때 적절한 고려가 주어진 경우 양쪽 모두를 가정하는 것이 공정하다고 생각합니다.

@bradfitz SemVer는 오늘날 Go 패키지에서 일반적으로 PHP, node.js, Rust 및 기타 수많은 언어에서 사용됩니다. 꽤 흔한 일입니다. 이러한 언어와 패키지가 SemVer 호환성 문제로 인해 중단되는 문제가 발생했습니다. 때로는 의도적으로 때로는 우연히. 사람들이 오류를 범할 수 있기 때문에 이러한 다른 모든 언어에 존재하는 문제를 피하기 위해 Go는 무엇을 다르게 할 것인가?

호환성이 항상 유지되고 개발자가 이를 조정하고 해당 정보를 종속성 트리 위로 전달하기 위해 액세스할 수 있는 손잡이가 없어야 한다는 잘못된 가정을 명확히 할 수 없다면.

모든 사람이 동의할 것이라고 생각합니다. 현재 종속성 관리 상황은 모든 언어/플랫폼에서 끔찍합니다. @bradfitz 가 충돌의 요점을 올바르게 설명했다고 생각합니다. vgo가 성공하지 못할 수도 있지만 나에게는 우리가 무언가를 변경해야 하는 것이 분명하며(Go에서뿐만 아니라 일반적으로) vgo가 시도해 볼 가능성이 매우 높아 보입니다.

@mattfarina 실제로 호환성이 유지되는지 자동으로 제어하는 ​​서비스를 구현하려고 합니다. godoc.org와 통합하고, README용 배지를 제공하고, go get의 프록시로 사용합니다. 충분히 잘 작동하도록 하는 방법에는 여러 가지가 있습니다. 물론 @sdboyer 가 API 호환성에 대해 옳다는 것은 실제 호환성을 보장하지 않지만 좋은 시작이며 대부분의 경우 충분히 잘 작동해야 합니다.

따라서 Go 커뮤니티의 규범이 바뀔 때까지 vgo는 Kubernetes를 사용하는 다종속성에서 한동안 작동하지 않을 수 있습니다.

희망은 전략이 아닙니다. 특히 기존의 행동과 기대가 이미 잘 확립되어 있는 경우에는 더욱 그렇습니다. 우리가 5년 전에 이 논의를 했다면 Go는 혁신 토큰을 여기에서 사용할 수 있었고 상황이 영향을 받기 더 쉬웠을 것입니다. 그러나 오랫동안 이 문제를 무시한 결과 지금 제안된 모든 도구는 사용자가 있는 곳에서 만나야 한다는 것이 분명해 보입니다.

사람들이 오류를 범할 수 있기 때문에 이러한 다른 모든 언어에 존재하는 문제를 피하기 위해 Go는 무엇을 다르게 할 것인가?

우리는 릴리스/태깅을 쉽게 만들면서도 API 호환성을 확인하는 일종의 go release 명령에 대해 논의했습니다(예: Go 릴리스용으로 작성한 Go 내부 go tool api 검사기). 또한 godoc.org 를 쿼리하고 패키지의 호출자를 찾고 태그가 푸시되기 전의 시험판 시간에 새 버전에 대해 테스트를 실행할 수도 있습니다. 등.

패키지의 호출자를 찾고 태그가 푸시되기 전에 출시 전 시간에 새 버전에 대해 테스트를 실행합니다. 등.

이것은 Google이 아닌 사람에게는 실제로 실용적이지 않습니다.

이것은 Google이 아닌 사람에게는 실제로 실용적이지 않습니다.

모든 클라우드 제공업체가 서비스로서의 컨테이너를 초 단위로 지불하기 시작하면서 누구나 실행하고 필요한 $0.57 또는 $1.34를 지불할 수 있는 오픈 소스 도구로 이것을 제공하지 못할 이유가 없습니다. 몇 분 동안 여러 호스트에 대해 엄청난 테스트를 실행합니다.

테스트 실행과 관련하여 Google의 비밀 소스는 많지 않습니다.

모든 클라우드 제공업체가 서비스로서의 컨테이너를 초 단위로 지불하기 시작하면서 누구나 실행하고 필요한 $0.57 또는 $1.34를 지불할 수 있는 오픈 소스 도구로 이것을 제공하지 못할 이유가 없습니다. 몇 분 동안 여러 호스트에 대해 엄청난 테스트를 실행합니다.

이를 위해서는 특정 클라우드 제공업체의 계정이 필요하며, 특정 클라우드 제공업체의 서비스 약관에 동의해야 합니다(전 세계 대부분이 이를 동의하지 않는 것처럼 취급하더라도 법적 이유로 동의하지 않을 수도 있습니다. 문제), 클라우드 제공자가 서비스하는 지역에 거주해야 하며(예: 귀하가 이란에 있고 클라우드 제공자가 미국에 있는 경우 수출법으로 인해 사용하지 못할 수 있음) 클라우드 제공자에게 지불할 돈이 있습니다(아마도 릴리스를 할 때마다). 많은 돈이 아닐 수도 있지만 그렇다고 해서 모든 사람이 지불할 수 있는 것은 아닙니다. Go가 포괄적이고 다양한 청중에게 사용되기를 원한다면 이것은 좋은 솔루션이 아닌 것 같습니다.

/2센트

@SamWhited MeteorJS는 클라우드 공급자에서 프로젝트를 실행하기 위해 내장된 meteor publish 명령인 Galaxy와 함께 작업했습니다. 내가 제기한 문제를 잘못 이해하고 있는 것일 수도 있지만, 문제에 대한 그들의 스윙은 괜찮아 보였습니다.

@bradfitz API는 변경되지 않지만 그 뒤의 동작은 변경되면 어떻게 됩니까? 그것은 SemVer에서 깨지고 그것을 가져오는 사람들에게 영향을 미치는 경우입니다. 이 상황을 어떻게 감지합니까? 한 번 이상 경험했기 때문에 질문합니다.

누구나 실행할 수 있고 $0.57 또는 $1.34를 지불할 수 있는 오픈 소스 도구는 몇 분 동안 여러 호스트에 대해 엄청난 테스트를 실행하는 데 필요합니다.

이것은 이제 비용에 영향을 미칩니다. 이것은 미국의 기술 도시에 있는 사람들에게는 괜찮게 느껴질 수 있습니다. 아프리카, 중앙 아메리카 또는 전 세계적으로 분포되어 있는 기타 지역의 사람들은 어떻습니까? 이러한 도구는 "기술 엘리트" 서클 외부에서 일반적으로 어떻게 액세스할 수 있습니까?

그리고 퍼블릭 클라우드 작업을 하지 않는 모든 경우는 어떻습니까? 온프레미스(많은 사람들이 수행) 또는 독점 및 신뢰 문제가 있습니다. 이 물건은 어떻게 작동할까요? 사내 도구가 있는 경우 사용 중인 수입품을 공공 서비스에 누설하고 싶지 않을 수 있습니다. GitHub에서 가져오기를 가져왔지만 이 서비스는 Google에서 실행된다고 가정해 보겠습니다. 사람들이 의존성 트리를 Google에 넘겨도 괜찮습니까? 무리는 그렇지 않습니다.

또한 태그가 푸시되기 전에 godoc.org를 쿼리하고 패키지 호출자를 찾고 시험판 시간에 새 버전에 대해 테스트를 실행할 수도 있습니다. 등.

Kubernetes를 예로 들어 보겠습니다. 누군가 Kubernetes로 가져온 패키지를 작성합니다. 따라서 도구는 이를 가져와 모든 테스트를 실행해야 합니다. 일부는 Windows 및 POSIX에서 실행되도록 설계되었습니다. 다중 OS/다중 아키텍처를 테스트할 수 있습니까(Go에서 처리하므로). 그것은 실제로 어떻게 생겼습니까 (및 비용)?

--

나는 이런 도구가 유용할 수 있다고 생각합니다. 나는 사람들이 다른 생각을 하게 하려는 것이 아닙니다. 나는 그들이 많은 사람들의 문제를 어떻게 해결하는지 알지 못합니다. 그것들은 충분히 실용적이지 않거나 모든 설정에 맞지 않습니다.

알려지고 제어 가능한 제약 조건으로 수학적 문제를 해결하려는 것처럼 느껴집니다. 그러나 사람들은 지저분하므로 내결함성 솔루션이 필요합니다.

오늘 일찍 @technosophos 를 인용하려면:

"버전 관리자는 실제로 컴파일러나 링커 등을 위한 도구가 아닙니다... 버전 관리자는 협업하는 사람들을 위한 것입니다."

그만한 가치가 있기 때문에 그는 한 명 이상의 종속성 관리자를 작성했고, 다른 사람을 연구했으며, 훨씬 더 많이 작성한 사람들과 이야기를 나눴습니다.

접근 방식에 대한 근본적인 우려가 여전히 남아 있는 상태에서 제안을 수락하는 것은 무책임하게 느껴집니다. 작성자와 커뮤니티 도메인 전문가 @sdboyer 간의 합의는 제안이 수락된 것으로 간주되기 전에 도달해야 하는 합리적인 최소 기준인 것 같습니다.

여기에 약간만 더하면: 우리는 비표준 및 차선책( go get 생태계)인 패키징에 대한 역사를 가지고 있습니다. "표준" 도구와의 호환성이라는 이름으로 사람들을 나쁜 관행으로 몰아가는 또 다른 go get 를 출시하는 것보다 표준 패키지 관리자를 포기하는 것이 더 나을 것입니다. 바둑이 공개된 이후로 바둑을 사용해 온 사람으로서 나는 바둑 팀의 리더십이 go get ( goinstall 필요)로 범한 실수에 대한 교훈을 배우지 못한 것 같아서 이 대화가 답답하고 낙담스럽다는 것을 알게 되었습니다.

이 제안에 대해 목소리를 낸 합리적이고 실용적인 문제가 있습니다. 우리는 단순히 "의도한 대로 작동한다"고 말하지 말고 이를 해결하도록 제안을 변경해야 합니다. 1.11, 1.12, 1.13에서 제대로 할 수 없다면 제대로 할 수 있을 때까지 기다려야 합니다. 이 제안은 좋은 방식이 아닌 대부분의 다른 시스템과 상당히 다르게 동작하는 시스템을 제안합니다.

MVS 뒤에 있는 동기 부여 이유는 전통적인 접근 방식이 NP-Complete인 것 같습니다. 나는 그것이 매우 열악한 동기라고 생각합니다. NP-Complete 문제를 다룰 때 주요 질문은 " 어려운 경우가 얼마나 자주 발생합니까?"입니다. 패키지 관리를 사용하면 답이 "매우 드물게" 나타납니다. 문제에 대한 NP-HARD 레이블을 피하기 위해 불완전하고 도움이 되지 않는 문제 공식화에 만족해서는 안 됩니다.

대부분의 구체적인 요점은 이 문제에 더 가까운 다른 사람들( @sdboyer @peterbourgon @mattfarina 등...)에 의해 표명되었습니다. 나의 주된 불만은 이러한 구체적인 사항이 적절하게 다루어지지 않았을 때 우리가 이 제안을 수락한다는 것입니다.

@SamWhited , 가상 디자인의 선택적 기능에 대해 문제를 제기하고 있습니다. 클라우드 제공자를 신뢰하지 않거나 해당 국가의 방화벽 내에서 클라우드 제공자를 사용할 수 없거나 비용을 지불하고 싶지 않은 가상의 사용자는 밤새 자신의 컴퓨터에서 항상 테스트(또는 그 일부)를 실행할 수 있습니다. 또는 go release 서명 확인을 사용하면 95% 무료입니다.

@mattfarina , @SamWhited , 토론을 https://github.com/golang/go/issues/25483으로 이동합시다.

@mattfarina

이러한 언어와 패키지가 SemVer 호환성 문제로 인해 중단되는 문제가 발생했습니다. 때로는 의도적으로 때로는 우연히. 사람들이 오류를 범할 수 있기 때문에 이러한 다른 모든 언어에 존재하는 문제를 피하기 위해 Go는 무엇을 다르게 할 것인가?

vgo가 이러한 경우에 dep보다 성능이 더 나쁜 것으로 가정되는 이유는 여전히 나에게 명확하지 않습니다. 오히려 vgo가 더 나은 성능을 보이는 것 같습니다. 블로그 게시물 에서 vgo 모델의 실패에 대한 증거로 helm의 특정 문제를 언급했습니다. 그러나 vgo 세계에는 vgo가 grpc에 v1.4.0을 사용하기로 선택한 두 가지 시나리오가 있습니다.

1. helm의 개발자는 go.mod grpc >= v1.4.0 를 요구 사항으로 지정하기로 결정했습니다. 이 경우 단순히 이 요구 사항을 되돌려 자신에게 적합한 이전 버전의 grpc 로 롤백할 수 있습니다.
2. helm 종속성의 개발자는 grpc >= v1.4.0 를 지정하기로 결정했습니다. 이 경우 dep도 설치했으며 helm이 grpc < v1.4.0 를 제한하여 롤백하려고 하면 충돌하는 요구 사항 때문에 dep가 삐걱거려야 합니다.

그래서 제 생각에는 vgo가 최소한 dep만큼 이 문제를 해결하는 것 같습니다. 한편, dep 세계에는 또 다른 옵션이 있습니다.

1. helm 의 전이적 종속성은 grpc >= v1.x.0 가 필요했고 x < 4 $ 가 있었고 grpc 는 v1.4.0 $를 릴리스했으며 dep는 묻지 않고 설치 시 최신 버전을 사용하기로 결정했습니다. . 이 경우 조타 장치가 고장나고 버그 수정 릴리스(귀하의 게시물에 설명된 대로)를 수행하기 위해 모여들어야 하며, 이로 인해 수고가 발생합니다. 한편 vgo는 새 버전을 무시하고 계속해서 잘 작동할 것입니다.

나는 분명히 기본적인 것을 간과하고 있습니다. 그러나 지난번에 slack에서 이에 대한 설명을 요청했을 때 가상의 미래 블로그 게시물로 연기되었습니다. 따라서 내 좌절감은 vgo에서 아이디어가 어디에서 왔는지 이해하지 못하기 때문에 dep보다 사람들이 버전의 의미를 깨는 데 더 많은 문제가 있습니다.

명확히 하자면 이것은 dep 에 대한 것이 아닙니다. MVS(vgo)가 다른 SAT-solver 기반 패키지 관리 솔루션(dep 포함)과 비교하여 어떻게 동작하는지에 대한 분석입니다.

Matt의 또 다른 예 는 다음과 같습니다.

당신은 app 모듈의 개발자이며 두 가지 종속성이 있습니다.

• grpc [>= 1.8 ]
• helm , 다음 종속성이 있습니다.
  
  
  
  • grpc [>= 1.0, < 1.4]( grpc 가 1.4에서 주요 변경 사항을 도입했기 때문에).
  
  

대부분의 사람들은 이행 종속성 요구 사항( helm -> grpc [>= 1.0, < 1.4])에 대해 알지 못합니다 helm grpc >= 1.4를 사용합니다. 나는 그것이 대다수의 사람들이 그것에 대해 관심을 가지거나 그것을 조사하는 데 시간과 에너지를 소비하는 것이 아니라고 가정합니다.

vgo(특히 MVS에 의존)를 사용하는 경우 다음을 얻게 됩니다.

• helm
• grpc [>= 1.8 ]

이것은 잘못된 조합이어야 하며( helm 요구 사항이 충족되지 않기 때문에) 대부분의 dep 관리자는 충돌이 있다는 오류 메시지를 표시합니다( helm 가 일부 문서에서 요구 사항을 명시한 경우). 체재).

이것은 MVS와 vgo에 대한 비판의 중요한 포인트입니다. 전체 SAT 해결이 필요하지 않도록 특정 버전에 문제가 있는 경우 종속성이 명시되는 것을 허용하지 않습니다. 자세한 설명은 MVS 문서 의 Theory 및 Excluding Modules 섹션을 참조하세요.

MVS는 SemVer가 항상 존중되고 따라서 이것이 필요하지 않다는 가정 하에 이 가능성을 인정하기를 원하지 않습니다(또는 적어도 현재 모듈에 지시하는 기능을 제한하기를 원함). 실제로 항상 그런 것은 아닙니다. 이전 버전과의 호환성을 고수하는 것이 어렵고 강제로 vgo 방식을 사용하는 경우 비실용적인 이유를 보여주기 위해 이전 버전과의 호환성에 대한 귀하의 기사를 참조할 것입니다.

MVS 솔루션은 모듈 개발자 에게 이러한 비호환성에 대해 종속성 작성자가 공유할 수 있는 지식을 무시하고 제외할 버전을 지정하도록 요청하는 것입니다. 따라서 대부분의 dep 관리자가 어떤 버전의 종속성이 서로 호환되는지(즉, SAT 해결) 파악하기 위해 거쳐야 하는 복잡한 논리를 알고 수행해야 하는 책임을 개발자에게 전가합니다.

사람들이 마법처럼 SemVer를 따르기 시작하지 않는 한, vgo를 사용하여 모듈을 가져온 후 호환되지 않는 버전 목록을 복사하기 위해 README 파일을 확인해야 하는 괴상한 연습으로 변환할 때 종속성을 설치하는 것을 상상할 수 있습니다. go.mod 파일에 있습니다. exclude 문은 현재 하나의 버전만 사용합니다.

@메로비우스

@mattfarina 의 블로그 게시물에서 의도적으로 grpc v1.4.0으로 업그레이드하는 Helm을 설명합니다. 즉, go.mod 를 업데이트하는 것과 같습니다. 문제는 dep 또는 vgo가 이 문제를 피하는 방법이 아니라 라이브러리 작성자가 이 문제에서 복구할 수 있도록 하는 방법입니다. dep의 경우 grpc<v1.4.0 제약 조건을 추가하는 패치를 릴리스할 수 있습니다. grpc에 대한 다른 종속성이 없는 사용자의 경우 이것이 작동합니다. 사용자가 이미 최신 버전의 helm으로 업데이트했고 grpc>=v1.4.0 에 대한 또 다른 종속성이 있는 경우 이 제약 조건으로 인해 빌드가 실패합니다. 이상적이지는 않지만 미묘하게 깨진 런타임 동작보다 낫습니다.

vgo 를 사용하면 Helm 유지 관리자가 이에 상응하는 옵션을 사용할 수 있습니까? 사용자가 어떤 이유로든 grpc를 v1.4.0으로 업그레이드했다면 MVS는 항상 [email protected] 을 선택하고, Helm은 중단되며 Helm 유지 관리자가 이에 대해 할 수 있는 일은 없습니다(변경된 동작에 대한 조정 제외, 종종 시간 소모). @mattfarina 에 대해 말할 수는 없지만 제기된 우려 사항을 읽고 공유하는 내용입니다. dep 및 이와 유사한 시스템을 사용하면 중간 라이브러리가 상한 제약 조건이 있는 호환성 위반을 방어할 수 있습니다(또는 더 자주 복구할 수 있음).

@ibraho @mattfarina

GopherconSG 토크에서 Russ의 예 중 하나가 매우 유사한(동일한?) 시나리오를 다루는 것 같습니다.

위의 게시물에서 helm이 "grpc [>= 1.0, < 1.4]"에 의존한다고 말했습니다. 그러나 그것은 엄격하게 정확하지 않습니다. 당신이 의미하는 바는 일부 특정 버전의 helm이 "grpc [>= 1.0, < 1.4]"에 의존한다는 것입니다. helm 버전이 2.1.3이라고 가정해 보겠습니다. 아마도 이 버전의 helm은 grpc 1.4 이후에 출시되었을 것입니다(그렇지 않으면 grpc 1.4와 호환되지 않는 것으로 표시되지 않았을 것입니다). 그 이야기에서 Russ의 요점은 helm의 이전 버전(예: 2.1.2)은 아마도 (아직) grpc 1.4와 호환되지 않는 것으로 표시하지 않았을 것입니다.

다시 말해, 만족스러운 할당(dep에 따라)은 helm = 2.1.2, grpc = 1.8일 것입니다. Dep는 주어진 버전에서 모든 제약 조건을 충족하므로 오류 없이 이 버전 할당을 올바르게 선택할 수 있습니다.

@balasanjay

Helm의 버전은 기본적으로 예제를 변경하지 않습니다. [email protected] 는 [email protected] 에 대한 종속성을 선언할 수 있고 helm 사용자는 직접 또는 다른 패키지를 통해 [email protected] 에 대한 종속성을 가질 수 있습니다. 이 시나리오에서 MVS는 실패하고 [email protected] 및 [email protected]을 설치합니다. 게다가, 이 예제는 문제가 밝혀지기 전에 사용자가 의도적으로 [email protected] (따라서 [email protected]) 및 아마도 [email protected] , [email protected] 등으로 업데이트한다고 가정합니다.

MVS는 이론적 목표를 달성하기 위해 의도적으로 중간 종속성에서 제외를 허용하지 않습니다.

부정적인 의미(X → ¬ Y, 동등하게 ¬ X ∨ ¬ Y: X가 설치된 경우 Y가 설치되지 않아야 함)는 추가할 수 없습니다...

이 예에서는 X= helm>= 2.1.3 가 설치되어 있으면 Y= grpc>=1.4.0 가 설치되지 않아야 한다는 표현이 필요하며 이는 의도적으로 수행할 수 없습니다.

실제로 최상위 패키지(손상을 수정하여)와 최하위 수준 사용자(수동으로 제외를 추가하여)만이 호환성 규칙이 깨졌을 때 어떤 수단도 가질 수 없습니다. Helm과 같은 중간체는 모든 종속성의 모든 향후 버전과 함께 작동해야 하며, 이는 나에게 그러한 라이브러리의 가치 제안을 크게 감소시킵니다.

아마도 이는 grpc 및 aws-sdk-go와 같이 많이 사용하는 라이브러리에서 더 나은 동작을 장려할 것입니다. 모든 손상이 모든 당사자에게 느껴지고 해결하기 더 어려울 것이기 때문입니다. 그러나 항상 그렇게 쉬운 것은 아닙니다. "파손"이 실제로 파손이 아니라 일부 사용자에게는 의도하지 않은 결과를 가져오지만 다른 사용자에게는 도움이 되는 합법적인 행동 변화라면 어떻게 됩니까? 그러한 유형의 일은 드문 일이 아니며 업스트림 작성자는 해당 시나리오에서 변경 사항을 되돌리는 것을 주저할 것입니다.

나는 Russ만큼 명확하지 않다고 생각합니다. 다시 시도하겠습니다.

처음에 deps의 상태는 다음과 같습니다.
투구 2.1.2: grpc >= 1.0

그런 다음 grpc 1.4가 릴리스됩니다. Helm 개발자는 비호환성이 있음을 깨닫고 새 버전의 Helm을 푸시합니다.
투구 2.1.3: grpc >= 1.0, < 1.4

나는 Helm과 grpc의 몇 가지 새로운 기능에 의존하는 새 앱을 시작합니다(인수를 위해). 나는 다음과 같은 deps를 나열합니다.
투구 >= 2.0.0
grpc >= 1.4

위의 주장은 dep가 내재된 충돌을 인지하고 오류를 보고한다는 것입니다.

그러나 Russ는 충돌이 없는 버전 할당이 있기 때문에 사실이 아니라고 지적했습니다. 특히 dep는 helm 2.1.2 및 grpc 1.4를 사용하도록 선택할 수 있습니다. dep에 따르면, 이것은 helm 2.1.1이기 때문에 유효한 할당입니다. 3 은 grpc 1.4와 호환되지 않는 반면 2.1은 호환되지 않습니다. 2 는 모든 grpc >= 1.0과 호환됩니다.

다시 말해, dep는 아직 충돌을 기록하지 않은 버전으로 다운그레이드하여 충돌을 "수정"하도록 _유효하게_ 선택할 수 있습니다. 변경할 수 없는 버전이 있는 경우 이는 불가피해 보입니다. 따라서 dep도 https://codeengineered.com/blog/2018/golang-vgo-broken-dep-tree/를 잘못 처리하는 것 같습니다.

@balasanjay 물론입니다. 하지만 결국 Helm은 원하는 깔끔한 새 기능이 포함된 2.2.0을 내놓고 업그레이드하려고 하면 문제가 발생합니다.

(저는 vgo가 MVS 결과에 이 형식의 "충돌"이 있음을 알리기 위해 잘 설계된 UX를 가지고 있다면 이것이 잘 될 것이라고 조심스럽게 낙관합니다. 항상 많은 경고와 함께 OK가 아닌 문제.)

dep가 충돌을 감지하는 상황이 있다는 데에는 확실히 동의하지만, 해당 블로그 게시물에 제시된 것이 _아닙니다_(적어도 현재 제시된 버전 요구 사항이 아님).

그리고 FWIW, 충돌의 비교적 간단한 예를 위반하는 경우 보호 장치의 효과에 의문을 제기하는 것이 합리적이라고 생각합니다.

기록을 위해 나는 Russ의 예를 추적했습니다(이것은 인상적인 정도로 이것과 거의 동일합니다): https://youtu.be/F8nrpe0XWRg?t=31m28s

Re: 최소 버전 선택, 다음 상황을 해결하는 방법을 찾는 데 문제가 있습니다.

유지 모드의 인기 있는 라이브러리를 상상해 보십시오. 예를 들어 v1.2.3이 변경 없이 1년 넘게 나왔다고 상상해 보십시오. 다른 많은 라이브러리가 이에 의존합니다.
개발자가 와서 v1.2.3에서 만드는 속도 최적화를 실현합니다. API 변경 없이 라이브러리의 핵심 기능 속도를 10배까지 높입니다! 이것은 v1.3.0으로 출시되었습니다. 다음 해에는 이 패키지에서 더 이상 버그가 발견되지 않습니다.

의존하는 사람들은 어떻게 이 업데이트를 받게 됩니까? 그들은 v1.2.3에서 작동 할 수 있지만 v1.3.0이 분명히 더 좋습니다.

@daurnimator

의존하는 사람들은 어떻게 이 업데이트를 받게 됩니까?

각 응용 프로그램은 사용할 최소 버전으로 1.3.0을 설정해야 합니다.

글쎄, 오늘은 얼마나 어리석은 날인가! 😄

이 제안은 2개월 넘게 활발한 논의와 함께 공개되었습니다.

이 문제는 수년 동안 열려 있었고 이 모든 것에 대해 설정된 타임라인 rsc는 모든 것을 고려했을 때 인위적으로 매우 짧았습니다.

우리가 이야기해야 한다고 생각하는 이 제안에 대해 두 가지 반대가 있었습니다.

1. 제안은 비호환성과 관련하여 발생할 수 있는 모든 가능한 시나리오에 대한 기술 솔루션을 제공하지 못합니다.

이것이 내가 Russ에게 설명한 입장에 대한 암시라면 오해의 소지가 있는 캐리커처입니다. 이 주제에 대한 내 생각을 정리하는 데 그렇게 오랜 시간이 걸린 한 가지 이유는 잘못된 주장과 진술의 반복적인 사용이...솔직히 불안정하기 때문입니다.

말 그대로 모든 가능한 시나리오를 다룰 수 있다고 생각하는 사람은 없습니다. 문제는 MVS가 _실상적인_ 문제(SAT를 피함)만 해결하고, 실제로 훨씬 더 중요한 _new_ 문제를 대신 생성하며, 합리적으로 작동할 수 있는 중간 계층으로 효과적으로 기능할 수 없다는 것입니다.

이들은 관찰에 정확하지만 의도한 대로 작동합니다. 개발자가 gofmt 실행과 같은 Go의 다른 세부 사항에 적응한 것처럼 코드 작성자와 사용자는 라이브러리 사용 및 릴리스에 대한 일부 관행을 변경해야 합니다.

여기에서 제안된 변경 사항의 정도를 gofmt 실행과 비교함으로써 아무 도움도 되지 않습니다. 아마도 Go 개발자로서 수행하는 가장 무모한 활동일 것입니다.

Russ가 최근 Gophercon Singapore 연설에서 지적했듯이 비호환성에 대한 유일한 영구적인 해결책은 함께 협력하여 비호환성을 수정하고 Go 패키지 생태계를 유지하는 것입니다. vgo 또는 dep와 같은 도구의 임시 해결 방법은 개발자가 실제 문제를 해결할 시간을 줄 수 있을 만큼만 작동하면 되며 vgo는 이 작업을 충분히 수행합니다.

중요한 것은 _커뮤니티_입니다. 우리를. 소프트웨어 생태계를 만드는 사람들. 우리는 제한된 토큰을 유용한 협업에 사용하는 데 도움이 되는 도구를 만들어 더 나은 생태계에 도달합니다.

@메로비우스 :

나는 가상의 미래 블로그 게시물로 연기되었습니다. 따라서 내 좌절감은 vgo에서 아이디어가 어디에서 왔는지 이해하지 못하기 때문에 dep보다 사람들이 버전의 의미를 깨는 데 더 많은 문제가 있습니다.

이 모든 주장을 하나로 모으는 데는 시간이 걸리고 그것은 제 일상이 아닙니다. 오늘 밤에 끝내려고 했는데 아직 최종 편집 단계에 있습니다. 😢내일 아침...? 아무것도 고정되어 있지 않습니다!

문제는 MVS가 (SAT를 피하는) 환상적 문제만 해결한다는 것입니다.

정중하게, IMHO SAT 솔루션은 솔루션이 아니므로 저에게 MVS는 매우 실제적인 문제를 해결합니다.

IMHO SAT 솔루션은 솔루션이 아니므로 나에게 MVS는 매우 실제적인 문제를 해결합니다.

가능하다면 그 이유를 알고 싶습니까?

이 문제는 수년 동안 열려 있었고 이 모든 것에 대해 설정된 타임라인 rsc는 모든 것을 고려했을 때 인위적으로 매우 짧았습니다.

여기에서 분명히 상충되는 두 가지 아이디어를 볼 수 있습니다. 설문 조사는 종속성 관리에 조만간 솔루션이 필요하다는 것을 반복해서 보여주었습니다. 그러나 6개월이라는 일정은 제안을 검토하고 승인하기에 충분하지 않습니다.

나는 우리가 구현할 첫 번째 솔루션을 선택해서는 안된다는 것을 이해합니다. 그러나 시간은 요인 중 하나입니다. vgo에 대한 반대 제안은 아직 잘 정의되지 않았으며 실현되려면 몇 년이 걸릴 것입니다. 나는 Go 1.14의 매우 멋진 SAT 기반 솔루션보다 Go 1.11의 vgo를 선택하고 싶습니다.

이것은 또한 vgo 구현이 고정되어 있다고 가정합니다. 우리가 아는 한 vgo는 1.12 및 1.13 기간 동안 상당히 변경될 수 있습니다.

가능하다면 그 이유를 알고 싶습니까?

PCRE보다 Go의 정규 표현식을 선호하는 것과 같은 논리입니다. 프로그램이 2차/지수 최악의 복잡도를 갖는 알고리즘에 의존하는 것을 허용하지 않습니다.

우리는 vgo 가 go get 를 대체할 뿐임을 명심해야 합니다. 우리는 vgo go get vgo 를 비교해야 하며 존재하지 않는 것과 비교해야 합니다. "나쁜 것이 더 좋다"! 이제 구현 세부 사항에 집중하겠습니다.

FWIW, IMO는 완전한 SAT 솔버 없이 상한을 도입하는 것이 완전히 가능합니다. 생성된 솔루션이 최적이 되도록 하거나 기존 솔루션이 발견될 것이라고 보장하는 것은 불가능합니다. 필요한 경우 할 수 있습니다.

1. 상한선을 지정할 수 있도록 합니다.
2. MVS를 통해 해결할 때 무시
3. 모든 경계에 대해 찾은 솔루션을 확인하고 맞지 않으면 삐걱 거리십시오(이것이 주요 차이점입니다. 기존 접근 방식은 대신 다른 솔루션을 찾으려고 시도합니다).

그러면 MVS(병리학적 런타임이 없는 간단한 알고리즘)의 이점을 얻을 수 있어 비호환성을 표시하고 이를 정적으로 감지할 수 있는 가능성을 유지하지만 존재하는 경우 항상 솔루션을 찾을 수 있다는 보장을 포기하게 됩니다. 논쟁의 여지가 있지만, 당신 이 찾을 솔루션은 실제로 솔루션이 아닙니다. 왜냐하면 비호환성이 여전히 존재하고 알고리즘에 알려지지 않았기 때문입니다.

그래서 적어도 나에게는 MVS의 상한선을 얻기 위해 어떤 식으로든 개조하는 것이 완벽하게 가능한 것처럼 보일 것입니다. 나는 그것이 실제로 필요하다는 것을 여전히 확신하지 못하지만, 그것이 사실로 밝혀지면 나중에 언제든지 추가할 수 있습니다. "MVS는 근본적으로 부적합하다"는 주장을 문제로 만드는 것입니다. 그러나 나는 여전히 문제를 오해할 수 있습니다. 그리고 그것을 더 잘 보여주는 실패 시나리오가 있을 수 있습니까?

@sdboyer 걱정 마세요. 내가 말했듯이, 나는 이것이 당신의 일상이 아니라는 것을 완전히 이해하고 참여하는 데 시간을 할애해 주셔서 감사합니다. 여전히 "논증을 모르면 논할 수 없다"는 현실적인 문제다. 나는 당신이 나만큼 전체 상황에 좌절감을 느꼈을 것이라고 상상할 수 있습니다. :)

PCRE보다 Go의 정규 표현식을 선호하는 것과 같은 논리입니다. 프로그램이 2차/지수 최악의 복잡도를 갖는 알고리즘에 의존하는 것을 허용하지 않습니다.

@cznic 저는 종속성 관리가 기술적인 문제일 뿐만 아니라 사회적 제약 및 고려 사항과 얽혀 있다는 의견입니다. 따라서 정규식과 비교하고(순전히 기술적인 구현 문제) 시간 복잡성을 기반으로 기본적으로 알고리즘을 선호하는 것이 공정한 접근 방식인지 확신할 수 없습니다.

MVS가 더 간단하고 추론하기 쉽고 당면한 문제의 다른 측면을 해결 한다면 이해할 수 있는 고려 사항이기 때문에 MVS를 선호하는 사람들이 있습니다.

사람들이 SAT 기반 알고리즘보다 선호하는 다른 이유가 있는지 궁금합니다.

사람들이 SAT 기반 알고리즘보다 선호하는 다른 이유가 있는지 궁금합니다.

@ibrasho MVS에는 잠금 파일이 필요하지 않습니다.

사람들이 SAT 기반 알고리즘보다 선호하는 다른 이유가 있는지 궁금합니다.

개인적으로 이유는

1. 잠금 파일과 매니페스트를 하나의 파일로 통합하며 대부분 컴퓨터에서 편집할 수 있습니다. 일반적인 경우에 재현성(또는 "고충실도") 빌드를 얻는 동안 노이즈가 적다는 의미입니다. AFAICT 이것은 MVS만의 고유한 것입니다. 다른 패키지 관리자에 대한 나의 주요 불만 중 하나는 매니페스트 파일을 편집해야 하는 수고이기 때문에 이것은 나에게 엄청난 일입니다.
2. 점진적인 수리가 더 쉬워질 것입니다/가능하게 될 것입니다. 저는 분산 개발 문제를 해결하기 위한 이 접근 방식을 굳게 믿고 있기 때문에 이것은 저에게도 중요합니다.
3. 대부분의 도서관에서 생태계가 집합적으로 HEAD에 가깝게 유지하는 데 도움이 될 수 있습니다. 이것은 대부분 추측이며 사용 가능한 도구에 따라 다릅니다. 그러나 "모든 것을 최신 버전으로 가져오기"가 충분히 간단하다면 프로덕션에서 최신 버전의 라이브러리가 서로 테스트되는 주기가 늘어날 수 있습니다.
4. 다른 접근 방식인 AFAICT의 바람직한 특성을 유지하거나 능가하면서 이 모든 것을 달성합니다. 업그레이드는 원하는 경우에만 발생합니다. 그리고 바이너리 패키지는 새 버전에서 일부 종속성 빌드가 손상되더라도 계속 빌드되므로 작성자에게 수정 작업을 수행할 시간이 주어집니다.

특히 이 마지막 부분은 좀 아이러니하다. 이 정확한 품질은 @sdboyer 의 지난 게시물에서 매우 중요하게 그려졌기 때문에 - 그러나 이 시점에서 나는 여전히 vgo가 이 점에서 전통적인 접근 방식보다 엄격하게 더 낫다고 믿습니다.

@메로비우스
"잠금 파일과 매니페스트를 하나의 파일로 통합합니다."

• 매니페스트가 파일 전체에 효과적으로 흩어져 있기 때문에 이것은 완전히 사실이 아닙니다. Import 문은 효과적으로 매니페스트 역할을 합니다.

@docmerlin 내가 "매니페스트"라고 말했을 때, 나는 당신이 의존하고 있는 모든 모듈을 적절한 버전과 함께 나열하는 파일을 의미했습니다(특히, 여기에는 import 문보다 엄격하게 더 많은 정보가 포함되어 있습니다. 그렇지 않으면 필요하지 않을 것입니다). vgo의 경우 go.mod , dep 의 경우 Gopkg.toml 입니다. 종속성 솔버에 대한 구성 파일을 호출할 수도 있습니다. 다른 용어가 더 적절하다고 생각되면 내 의견을 읽을 때 매니페스트를 자유롭게 대체하십시오.

파일당 모든 종속성을 나열하는 파일과 명시적 가져오기 목록(잠재적으로 종속성의 잠재적으로 엄격한 하위 집합임)이 모두 있는 것은 매우 정상적입니다. 특히 내가 알고 있는 모든 Go 종속성 관리자는 그렇게 합니다. 다른 접근 방식은 또한 재현 가능한 빌드를 보장하기 위해 사용할 특정하고 정확한 버전을 설명하는 잠금 파일을 사용합니다. 그리고 내가 언급한 MVS의 구별되는 기능은 이 파일이 manifest/dependency-solver-config/go.mod 파일에서 고유하게 파생될 수 있기 때문에 필요하지 않다는 것입니다.

(내 개인 계정에서 삭제 + 다시 게시)

@cznic MVC의 복잡성 클래스와 SAT 기반 접근 방식을 따로 분리하는 것은 이치에 맞지 않습니다. 이름/식별).

vgo에 대한 몇 가지 우려 사항을 해결하기 위한 #25483의 @bradfitz 제안(처음에는 미친 것 같지만 아마도 훌륭한 실용적인 솔루션일 수 있음)에는 릴리스 전에 API의 임의 사용자로부터 테스트를 실행하는 것이 포함됩니다. 이것은 일반적으로 NP-완전한 문제이지만 실제로는 gps2와 같은 훌륭한 솔루션이 될 수 있습니다.

따라서 한편으로는 SAT 기반 패키지 관리 알고리즘이 있고 다른 한편으로는 나중에 NP 완료 작업을 수행하도록 강제하는 NL 알고리즘이 있습니다(또는 실제 SAT 솔버가 수행하는 시간 초과). 적대적 잠금 파일의 경우).

MVC의 복잡성 클래스와 SAT 기반 접근 방식에 대한 개별적인 초점은 이치에 맞지 않습니다 ...

'집중'이라는 용어가 어디에서 유래했는지 모르겠습니다. 사용 가능한 두 가지 알고리즘이 있는 경우 하나의 최악의 경우는 2차 또는 더 나쁨이고 다른 하나는 선형 od 더 나은 경우 후자를 선택하고 전자를 피합니다. 나는 그것을 초점이 아니라 원칙이라고 부르고 싶다.

... vgo에 대한 몇 가지 우려 사항을 해결하기 위한 #25483의 제안 ...

문제 #25483은 vgo와 관련이 없는 것 같습니다. 오식?

사용 가능한 두 가지 알고리즘이 있는 경우 하나의 최악의 경우는 2차 이하이고 다른 하나는 선형 이상인 경우 후자를 선택하고 전자를 피합니다.

@cznic 확실히, 일반적으로 두 개의 알고리즘이 동일한 결과를 제공하는 경우 복잡성이 낮은 알고리즘을 원합니다(항상 그렇게 잘리고 건조한 것은 아니지만 Python은 복잡성 경계가 더 나쁨에도 불구하고 더 나은 결과를 갖기 때문에 작은 입력에 대해 삽입 정렬 을 사용합니다. 상수 + 런타임까지).

이 경우(MVS vs. SAT 기반 알고리즘) 결과는 목적에 따라 다르며 광범위한 결과를 낳습니다. 이 때문에 알고리즘 복잡성을 비교할 수 없으며 더 광범위한 영향을 고려해야 합니다.

문제 #25483이 vgo와 관련이 없는 것 같습니다.

해당 문제의 첫 번째 줄은 이 문제에 대한 Brad의 의견에 대한 링크입니다. https://github.com/golang/go/issues/24301#issuecomment -390788506 . 이 도구는 vgo 외부에서 유용할 것이지만 MVS의 일부 단점을 완화하기 위해 주로 고려되는 것 같습니다(내 의견/이해).

그렇군요 댓글이 많네요. 도움이 되도록 몇 가지 세부 정보와 기록을 추가하려고 합니다.

몇 년 전만 해도 다양한 종속성 관리 솔루션(예: godep, glide 등)이 있었습니다. 앞으로의 경로를 파악하기 위해 몇 가지 일이 발생했습니다.

1. 투자하고 지식이 풍부한 사람들의 그룹이 한 위원회에 모 였습니다. 참고로 Google의 go 팀 구성원은 이 그룹에 속해 있었습니다.
2. 종속성 관리자를 작성했거나 관련 정보를 갖고 있는 두 번째 그룹이 이 첫 번째 그룹을 지원했습니다.
3. 기존 도구(Go 내부 및 외부)에 대한 필요와 생각에 대한 커뮤니티 설문조사가 수행 되었습니다. 일부 결과는 위원회의 눈에만 비공개였습니다.
4. Go를 프로덕션에 사용하는 회사를 인터뷰하여 요구 사항에 대한 세부 정보를 얻었습니다. 자세한 내용은 공개되지 않아 사람들이 자유롭게 말할 수 있습니다.

설문 조사 및 인터뷰 데이터는 모두 위원회에 피드백되었습니다. 데이터를 살펴보고 토론한 후 그들은 우리가 특정 기능을 갖춘 솔루션이 필요하다고 결정 하고 사양 을 만들었습니다. 그 후 dep의 개발은 이러한 요구 사항을 충족하기 시작했습니다.

작년 Gophercon에서 종속성 관리에 투자한 사람들이 이에 대해 이야기하는 기고자 회의 가 있었습니다. 대화가 끝나갈 무렵 Russ가 테이블로 다가와 이렇게 말했습니다. 그는 그렇게 했고 vgo를 생각해 냈습니다. 커뮤니티와 별도로 진행되었습니다.

vgo는 설문조사와 인터뷰에서 사람들이 표현한 요구 사항을 충족합니까? 내가 Russ에게서 수집한 것에서 그는 결과를 읽지 않았지만 그는 그 과정을 비판했습니다. 누군가 매핑을 할 가치가 있을 수 있습니다.

오, 회담에서 Russ는 그 당시 SAT 해결사를 좋아하지 않았던 이유 중 하나를 공유했습니다. 그는 많은 코드를 유지 관리해야 하는 Google의 Go 팀을 원하지 않았기 때문에 코드 줄 수가 적은 솔루션을 원했습니다. 차이점을 더 잘 이해하기 위해 dep, glide 및 기타 도구 간의 LOC 비교를 수행했기 때문에 특히 기억합니다.

Go는 Google이 소유하고 운영하는 프로젝트입니다. 문제가 리소스 중 하나라면 Go는 재단 아래 있어야 하고 다른 조직의 사람들이 소유권에 참여해야 합니까? 이는 도구 체인을 유지 관리하기 위해 리소스를 추가하는 또 다른 방법입니다.

아니요, #25483은 vgo와 관련이 없습니다. 가상의 go release 도우미 명령이 수행할 수 있는 또 다른 종류의 것으로 그냥 나열했습니다. 그러나 언제든지 유용할 것입니다.

내 주요 요점은 Go가 Go 패키지 릴리스를 매우 쉽게 만들지 않았다는 것입니다. 전생에 Perl CPAN 패키지의 릴리스를 자동화하기 위해 http://search.cpan.org/dist/ShipIt/ 을 작성했으며 이러한 작업을 도구로 사용할 때와 손으로 수행할 때 큰 차이를 만들었습니다.

나는 인간이 실수하지 않도록 돕기 위해 Go가 다르게 할 수 있는 일을 물었 기 때문에 가상의 go release 에 대해서만 언급했습니다.

vgo에서 볼 수 있는 실제 문제는 해결하기가 쉽지 않은 것 같습니다.... 최대 버전 문제입니다. 하나의 라이브러리가 dep의 v1.7로 중단되는 경우 제외하는 것 외에는 지정할 방법이 없습니다. 이는 v1.8이 나올 때까지만 도움이 되며 여전히 똑같은 방식으로 중단될 수 있습니다.

vgo가 두 라이브러리가 호환되지 않을 때 결정하는 데 도움이 되는 방법으로 vgo에 최대 버전을 추가하는 것은 사소한 일인 것 같습니다. 한 라이브러리에 최소 v1.7이 필요하고 한 라이브러리에 필요하다고 표시되는 경우

이것이 없으면 vgo는 1.7만 사용하고 라이브러리 중 하나가 중단됩니다. 운이 좋다면 컴파일러 오류가 있습니다. 길을 갈 때까지 알아차리지 못할 수 있는 미묘한 동작 버그가 있을 가능성이 더 큽니다. 그리고 교활한 것은 아마도 직접 호출하지도 않는 전이적 종속성일 수 있다는 것입니다.

@natefinch 최대 버전 제한은 MVS를 매우 영리한 회피 SMT 솔버 영역에서 밀어냅니다.

@natefinch 는 최종 확인/필터로서 최대 버전을 의미한다고 생각합니다. MVS가 작업을 완료하면 이러한 최대 버전 제한 중 하나라도 충족되지 않으면 vgo에서 오류가 발생합니다. 그것은 여전히 ​​우리를 SAT 솔버 영역으로 데려가지 않습니다.

정확히. 해결 방법이 없습니다. "vgo는 1.7을 사용하는 것이 옳다고 말하지만 모듈 X는 해당 버전에서 작동하지 않는다고 말합니다"가 있습니다. 이것은 이미 require foo 1.7 라고 하는 것이 있고 더 높은 foo 버전이 없으면 exclude foo 1.7 라고 하는 것이 있으면 vgo에서 오늘 일어날 수 있는 일입니다.

그러면 어떻게 해야 합니까?

기계적 해결책이 없기 때문에 해결책을 찾기 위해 인간의 두뇌를 사용합니다. 호환되지 않는 버전의 라이브러리가 필요하다고 명시한 두 개의 라이브러리를 사용하려고 합니다. A는 1.6으로 깨지고 B는 1.7로 깨집니다. 끝.

종속성 작성자에게 버그를 수정하도록 설득하거나(버그인 경우) 라이브러리 작성자 중 한 명이 새 종속성 버전과 호환되는 새 버전을 출시하도록 설득하거나, 많은 항목을 분기하여 직접 수정해야 합니다. .

좋은 대답은 없습니다. 그러나 이 문제를 해결할 수 있는 도구도 세상에 없습니다.

@sdboyer

문제는 MVS가 (SAT를 피하는) 환상적 문제만 해결한다는 것입니다.

나는 Russ와의 사적인 대화에 대해 말할 수 없지만 "SAT를 피하는 것"은 나에게 횡설수설한 논쟁처럼 보입니다. "SAT를 피하는 것"은 "SAT를 사용하는 것"보다 더 이상 목표가 아닙니다. 둘 다 사용자에게 구체적인 영향을 미치지 않습니다.

내가 보기에 MVS가 해결하는 구체적인 문제는 다음과 같습니다.

• 기본적으로 빌드를 재현 가능하게 만들기,
• 가능한 한 테스트된 버전에 가깝게 구축하고,
• 가짜 거절을 피하는 것.

우리는 제한된 토큰을 유용한 협업에 사용하는 데 도움이 되는 도구를 만들어 더 나은 생태계에 도달합니다.

나는 동의한다. 그러나 귀하의 가정을 자세히 살펴보고 싶습니다. 어떤 도구가 참여를 "벌"하고 그 이유는 무엇입니까?

게시물에서 제공한 예 중 하나는 "우리 프로젝트는 현재 [email protected] 에 의존하지만 [email protected] 이상에서는 작동하지 않습니다. 우리는 좋은 시민을 원하고 적응하기를 원하지만 지금은 대역폭이 없습니다.”

첫 번째(암시적) 가정은 귀하(또는 귀하의 사용자)가 종속성의 모든 릴리스에 대해 철저하게 프로젝트를 테스트할 시간과 대역폭이 있다는 것입니다.¹ 일부 프로젝트의 경우 그 가정 자체가 성립하지 않을 수 있습니다. : 모든 사람이 비호환성을 발견할 때 상한선에 태그를 지정한다는 기대치를 설정하면 잠재적으로 모든 릴리스에서 회귀 및 업데이트 경계를 테스트할 대역폭이 없는 유지 관리자를 "처벌"하게 됩니다.

대조적으로, MVS에서 유지 관리자는 " [email protected] 에 대해 철저히 테스트했으며 작동했습니다."라는 한 가지만 선언해야 합니다. 사용자가 이를 방해하기 위해 아무 것도 하지 않으면 [email protected] 에 대해 빌드하고 모든 것이 이전과 같이 계속 작동합니다.

MVS에서 _breakage는 명시적 업그레이드 시에만 발생합니다._ 이는 상당한 이점입니다. 사용자가 [email protected] 를 가져오고 패키지 사용을 중단하도록 다른 종속성을 업그레이드하면 간단히 할 수 있습니다. 수정할 시간이 있을 때까지 또는 X 의 유지 관리자가 비호환성을 수정할 시간이 있을 때까지 해당 업그레이드를 취소합니다._ 그리고 올바른 기대치를 감안할 때 후자가 전자보다 훨씬 더 가능성이 높습니다. $# [email protected] [email protected] 가 불필요한 바쁜 작업이 될 수 있습니다.

두 번째 가정은 모듈의 _모든 부분_에 영향을 미치는 모든 비호환성이 모듈의 _모든 사용자_에 영향을 미친다는 것입니다. 패키지에서 [email protected] 아래로 분류되는 부분이 거의 사용되지 않는 기능이라면 사용자가 호출하지도 않는 프로그램에서 X 를 업그레이드하지 못하게 하는 이유는 무엇입니까?

모듈의 일부가 다른 부분에 의존하지 않는다면 별도의 모듈이어야 한다고 주장할 수 있지만, 이는 다시 패키지 관리자에게 추가 작업을 강요합니다. 주기적으로 테스트하고 업그레이드할 대역폭만 있다면 세분화된 종속성이 있는 세분화된 모듈 전체가 아니라 하나의 모듈을 유지하기 위한 대역폭입니다.

¹ 일반적으로 종속성과의 비호환성을 감지하려면 해당 종속성의 _모든 릴리스의 외적_에 대해 테스트해야 합니다. [email protected] 의 특정 사용은 괜찮지만 의존하는 일부 다른 패키지와 결합하면 중단될 수 있습니다. 켜짐. 예를 들어, 귀하와 귀하의 종속성이 글로벌 구성에서 호환되지 않는 옵션을 요구할 수 있습니다.

그들은 단순히 그 업그레이드를 취소할 수 있습니다

이는 컴파일러 오류 또는 이와 유사하게 눈에 잘 띄는 것으로 가정합니다. 즉각적으로 드러나지 않는 미묘한 행동 버그일 가능성이 훨씬 더 높습니다. 업데이트하고 테스트를 실행하면 모든 것이 좋아 보입니다. 10초였던 타임아웃이 이제 30이 되었을 수도 있고, 로드 상태일 때 스택의 나머지 부분에서 타임아웃이 발생합니다. 프로덕션 환경에서 실행될 때까지 눈치채지 못할 것입니다(몇 년 전 mgo 변경으로 유사한 일이 발생했습니다).

[email protected] 에서 깨지는 패키지 부분이 거의 사용되지 않는 기능이라면 사용자가 X를 호출하지도 않는 프로그램에서 X를 업그레이드하는 것을 왜 보류합니까?

전이 종속성인 경우 해당 기능을 사용하는지 여부를 알 수 없고 코드를 변경할 때 일부 사용되지 않는 코드 경로가 갑자기 활성화되지 않을 것이라고 누가 말할 수 있습니까? 그래서 깨진 함수가 이제 호출됩니다. 자신의 라이브러리를 이해하는 데 전문가인 라이브러리 관리자를 신뢰하는 것이 훨씬 낫습니다. 1.7에서 작동하지 않는다고 말하면 1.7로 빌드하지 않는 것입니다.

이는 컴파일러 오류 또는 이와 유사하게 눈에 잘 띄는 것으로 가정합니다. 즉각적으로 드러나지 않는 미묘한 행동 버그일 가능성이 훨씬 더 높습니다.

거의 모든 소프트웨어 패키지의 거의 모든 버전에는 미묘한 버그가 숨어 있습니다. 우리는 일반적으로 그러한 버그를 발견했다고 해서 릴리스를 완전히 사용할 수 없는 것으로 표시하지 않습니다. 대신 이후의 포인트 릴리스에서 수정합니다.

이 특정 클래스의 버그를 특별하게 만드는 것은 무엇입니까?

코드를 변경할 때 일부 사용되지 않는 코드 경로가 갑자기 활성화되지 않을 것이라고 누가 말할 수 있습니까?

이것이 바로 MVS 인수입니다. 코드를 변경하면 _해당 개정판에서_ 손상을 감지하고 해당 개정판에서도 버전 제약 조건을 업데이트할 수 있습니다.

이는 사용자로서 종속성을 일괄적으로 업그레이드하는 것보다 한 번에 하나씩 종속성을 업그레이드하는 경우 실패를 양분하는 것이 더 쉽다는 것을 의미하지만 일반적으로 변경 사항이 사실입니다. 변경 사항이 작을수록 더 정확하게 할 수 있습니다. 코드 또는 종속성 변경 여부에 관계없이 이등분합니다.

이 특정 클래스의 버그를 특별하게 만드는 것은 무엇입니까?

그냥 버그가 아닙니다. 그것보다 더 큽니다. 그들의 코드에 대한 최고의 전문가인 라이브러리 작성자는 "야, X 버전 1.7이 내 자료를 너무 나쁜 방식으로 망가뜨렸어. 그걸로 빌드조차 하지 말라"고 말했다.

분명히 컴파일러 오류가 아닌 한 판단 요청입니다. 99개의 기능이 패닉을 일으키지만 하나는 그렇지 않은 경우... 그냥 버그인가요? 아니면 완전한 비호환성입니까? 당황하는 기능이 하나뿐이라면 어떻게 될까요?

언젠가는 인간이 결정을 내려야 합니다. 저는 선언되지 않은 주요 문제가 프로덕션 환경으로 들어가는 것에 대해 걱정하는 것보다 빌드 시 발생하는 사전 선언된 비호환성을 처리하는 것이 훨씬 낫습니다.

그냥 버그가 아닙니다. 그것보다 더 큽니다. 그들의 코드에 대한 최고의 전문가인 라이브러리 작성자는 "야, X 버전 1.7이 내 자료를 너무 나쁜 방식으로 망가뜨렸어. 그걸로 빌드조차 하지 말라"고 말했다.

라이브러리 작성자가 이것을 표현할 수 있는 또 다른 방법이 있습니다. 호환되지 않는 X 버전과 함께 사용할 때 실패하는 테스트를 작성합니다. 이는 X가 고정 버전을 릴리스할 때 라이브러리를 변경할 필요가 없고 미래의 회귀.

호환되지 않는 버전의 X와 함께 사용할 때 실패하는 테스트를 작성하십시오.

네, 생각했습니다. 그러나 모든 최상위 바이너리에 모든 전이적 종속성에 대한 모든 테스트를 실행하도록 요청하고 있습니다. 모든 테스트 스위트가 100% 격리된 것은 아닙니다.

go test ./... 가 공급업체 디렉토리에서 테스트를 실행하지 않는 이유가 있습니다.

요약하자면 (아마도 형편없겠지만) vgo에 대한 주요 기술 논쟁은 라이브러리가 자체 종속성에 대해 전역적으로 존중되는 제약 조건을 선언할 방법이 필요하다는 것입니다.

GPS2가 vgo 양측이 좋아하는 부분에 어떻게 맞을 수 있는지 탐구하는 경쟁 제안을 승인하는 데 양측이 동의하지 않는 이유는 무엇입니까? 그런 다음 vgo가 메인 라인을 병합하기 전에 그 동안 vgo 실험을 병합하고 GPS2 제안을 다시 방문하시겠습니까?

과거에 많은 종속성 도구로 어려움을 겪었던 사람으로서 저는 vgo에 대해 흥분합니다. FWIW는 "커뮤니티" 회원으로서 지금까지 vgo 솔루션으로 잘 대표되는 것 같습니다. 그러나 전역 버전 제약 조건을 추가하는 데 찬성하는 주장을 고려하는 데 열려 있으며 해당 주장이 더 발전하기를 기대합니다.

이것을 밖으로 던지면:

이는 컴파일러 오류 또는 이와 유사하게 눈에 잘 띄는 것으로 가정합니다. 즉각적으로 드러나지 않는 미묘한 행동 버그일 가능성이 훨씬 더 높습니다. 업데이트하고 테스트를 실행하면 모든 것이 좋아 보입니다. 10초였던 타임아웃이 이제 30이 되었을 수도 있고, 로드 상태일 때 스택의 나머지 부분에서 타임아웃이 발생합니다.

이것은 일반적으로 소프트웨어에서 발생하는 문제입니다. NPM(개인적으로 가장 친숙한 다른 버전 도구)은 semver를 강력하게 수용한 커뮤니티와 결합된 SAT 솔버를 사용하며 이 문제는 여전히 존재합니다.

전이적 종속성에 대한 논의가 있는 한 현실은 마술 지팡이가 없다는 것입니다. 어느 시점에서 개발자는 자신이 사용하는 종속성을 인식하고 궁극적으로 책임이 있는 코드를 적절하게 테스트할 시간을 투자해야 합니다. 법적 및 기타 이유로 이행 라이브러리를 포함하여 우리가 사용하는 모든 라이브러리를 정당화해야 하는 유일한 고용주는 아닙니다.

솔직히 제 눈에는 vgo에 대한 불만이 '완벽하지 않아서 안 된다'는 것 같아요. 완벽한 솔루션이 필요없는 좋은 솔루션을 구현하는 데 실패하지 맙시다.

제 생각에는 핵심 팀이 대부분의 상황에서 좋은 도구를 제공하고 더 발전된 특정 도구를 제공하도록 커뮤니티에 맡기는 것이 전반적인 Go 철학과 매우 일치하는 것 같습니다.

@malexdev 다음과 같은 주장에 액터에게 문제가 있을 수 있습니다.

완벽한 솔루션이 필요없는 좋은 솔루션을 구현하는 데 실패하지 맙시다.

dep는 오늘날 좋은 솔루션입니다. 커뮤니티가 함께 작업하여 만든 것입니다. vgo는 앞서 시작한 것처럼 몇 가지 가정을 합니다.

1. 아무도 우연히라도 semver에서 헤어지지 않도록
2. 기존 생태계에서 기존 코드베이스를 재작업해야 함

vgo는 "완벽한 세계"에서 "완벽한 솔루션"에 더 기반을 두고 있는 반면 dep는 내결함성을 유지하면서 다른 프로그래밍 언어 생태계에서 이미 작동하는 것을 따라 오늘날 작동합니다.

이것은 내가 방금 작성한 패키지 관리 문제 공간의 역사 에서 볼 수 있습니다.

요약하자면 (아마도 형편없겠지만) vgo에 대한 주요 기술 논쟁은 라이브러리가 자체 종속성에 대해 전역적으로 존중되는 제약 조건을 선언할 방법이 필요하다는 것입니다.

이 요약에 동의합니다.

GPS2가 vgo 양측이 좋아하는 부분에 어떻게 맞을 수 있는지 탐구하는 경쟁 제안을 승인하는 데 양측이 동의하지 않는 이유는 무엇입니까?

이 시점에서 나는 GPS2가 필요하거나 심지어 좋은 아이디어라는 확신이 없습니다. 위에 나열한 기능은 MVS( 이것 또는 이것 처럼) 위에 vgo로 개조될 수 있습니다. 개인적으로 @sdboyer 의 다음 블로그 게시물에 MVS 자체에 대한 좋은 주장이 포함되기를 바랍니다. 그러나 지금 당장은 다른 알고리즘, 특히 vgo의 상당한 UX 이점을 요하는 알고리즘에 대한 이유를 전혀 알 수 없습니다.

하지만, 공정하게 말하자면, 나는 또한 그것을 실험하는 것에 대해 어떤 이유도 보지 못합니다.

dep는 오늘날 좋은 솔루션입니다.

동의하는지 잘 모르겠습니다. 나는 그것을 직접 사용하지 않았지만 SAT 해결 접근 방식으로 직접 추적 가능한 문제에 대해 여러 사람들이 불평하는 곳에서 여유가 있습니다. 그리고 저는 deps 전체 디자인에 대해 매우 불행하다는 것을 알고 있습니다(종속성 솔버 자체에 대한 질문은 제외하고 일반적인 워크플로 및 UX).

1. 아무도 우연히라도 semver에서 헤어지지 않도록

죄송합니다만, 이 진술에 대한 정당성을 수차례 요청했지만 받지 못했습니다. vgo가 어떤 식으로든 dep 이상의 형태 또는 형태로 이것을 가정하는 이유는 무엇입니까? 나는 이 말에 근본적으로 동의하지 않는다. 알고리즘을 설명하기 위해 만들어진 가정입니다. 마치 dep의 알고리즘을 설명하는 것처럼 의미론적 버전에 내장된 가정을 설명합니다. 최악의 경우 이러한 의미 체계를 준수하지 않으면 동일한 손상이 나타납니다.

일반적으로 우리가 이야기하는 내용의 서로 다른 부분을 구별하는 것이 합리적이라고 생각합니다. 불만 중 일부는 SIV, 일부 MVS 및 일부 일반 vgo-shell에 관한 것입니다. 예를 들어, MVS가 상위 버전 경계를 처리할 수 없는 것은 사실이지만 vgo가 상위 버전 경계를 처리할 수 없다는 것을 의미하지는 않습니다. SIV는 (import 문을 다시 작성하여) 많은 코드를 변경해야 하지만, 다시 말하지만 이것이 vgo가 반드시 필요하다는 것을 의미하지는 않습니다. 분명히 말하지만, 나는 또한 우리가 마이그레이션할 수 있는 한 그렇게 큰 문제라고 생각하지 않습니다. 우리가 할 수 있는 AFAICT.

방금 @rsc 의 GopherConSG가 버전 관리에 대한 기조 연설 을 시작하는 것을 보았습니다. 그는 종속성이 주요 변경 사항을 도입하는 시나리오를 다루었고 vgo와 dep가 이를 처리하는 방법을 비교했는데, 이것이 여기서 주요 관심사인 것 같습니다. (훌륭한 시계입니다.)

그의 요점을 올바르게 이해했다면 잘못된 버전을 피하기 위해 최대 버전 제한이 사용되는 경우 dep도 빌드를 중단할 수 있습니다 . 나는 이 점에서 vgo가 dep에 미치지 못한다고 우려하는 사람들이 이 점을 언급하는 것을 보고 싶습니다.

@willfaught 우리에게 나쁜 버전을 피하기 위해 최대 버전 제한이 사용될 때 빌드를 깨는 것은 성공적인 것으로 간주됩니다! 이것이 우리가 원하는 일입니다. Russ는 이 문제가 자동으로 해결되지 않는다는 점을 정확히 지적합니다. Helm>2.0.0 에 대한 제약 조건은 사용자를 자동으로 " [email protected] "로 업그레이드하지 않지만 사용자가 명시적으로 "Helm ==2.1.4". 개인적으로 라이브러리 문제가 발생했을 때 가장 먼저 시도하는 것은 강제로 최신 버전으로 업데이트하는 것입니다. Dep를 사용하면 GRPC 1.4.0에서 발생한 오류를 알려줍니다. vgo 를 사용하면 Helm이 이를 나에게 전달할 수 있는 유일한 방법은 문서를 통해서입니다.

계속해서 이해되지 않기 때문에 요점을 반복합니다. dep 나 vgo 모두 이 문제가 발생하는 것을 방지하거나 완벽한 솔루션을 제공할 수 없습니다. 오히려 dep 를 사용하면 Helm이 문제가 있음을 알릴 수 있지만 vgo 는 그렇지 않습니다.

요약하자면 (아마도 형편없겠지만) vgo에 대한 주요 기술 논쟁은 라이브러리가 자체 종속성에 대해 전역적으로 존중되는 제약 조건을 선언할 방법이 필요하다는 것입니다.

호환성 규칙을 위반하는 불행한 경로를 처리하기 위해 이러한 제약 조건이 필요하다는 점에서 이 요약에 색상을 추가합니다. vgo 는 가져오기 호환성 규칙을 설정한 다음 항상 규칙을 따른다는 가정 하에 솔루션 개발을 진행합니다. 이 이상화된 세계에서 상한선에 대한 필요성은 제한적이거나 아예 존재하지 않습니다. 현실 세계에서는 이런 일이 일어나지 않을 것입니다. 개발자는 의도적으로든 그렇지 않든 호환성을 깨는 업데이트를 출시할 것입니다.

@Merovius 가 실행 가능한 솔루션에 있다고 생각합니다. MVS는 지정된 대로 진행되고 해결이 완료된 후 vgo는 해결된 각 패키지에서 제외를 확인합니다. 발견된 경우 최종 사용자에게 보고되며, 최종 사용자는 이러한 제약 조건을 충족하도록 종속성을 변경하거나 제약 조건을 무시하고 무시하도록 선택할 수 있습니다. 나는 이것의 반대편에 있었고 때로는 관리자보다 더 잘 알고 있습니다. 그것은 당신의 응용 프로그램에 대해 작동하며 그것이 당신이 걱정하는 전부입니다.

이렇게 하면 중간 라이브러리가 최종 사용자에게 비호환성을 전달할 수 있는 경로가 복원됩니다. helm 예제를 다시 반복하려면:

[email protected] : Helm @2.1.2
헬름 @2.1.2 : GRPC @1.3.5

==> 사용자가 의도적으로 [email protected] 으로 업그레이드합니다.

사용자: Helm @2.1.3, [email protected] ("Helm이 업데이트되어 마침내 grpc 1.4를 사용할 수 있습니다!")
투구: GRPC @1.4.0

==> 버그가 감지되었습니다! 사용자에게 Helm에 몇 가지 문제가 있으므로 새 버전을 확인하십시오.

사용자: [email protected] , [email protected]
투구: GRPC @1.3.5, 약한 GRPC <1.4.0

사용자에게 GRPC 1.4.0이 [email protected] 설치에 의해 거부되었다는 경고가 표시됩니다. Helm이 고장났고 이것이 제가 수정하려고 하는 것이기 때문에 GRPC 1.4.0(슬프게도 일부 유용한 기능을 잃음)에 대한 종속성을 제거하고 MVS를 다시 실행합니다. 이번에는 MVS가 GRPC를 1.3.5로, Helm을 2.1.4로 확인하고 모든 약한 제약 조건을 다시 확인하여 해당 제약 조건이 유지되는지 확인하면 완료됩니다.

이러한 문제를 마술처럼 해결할 수 있는 도구는 없지만 미들웨어 라이브러리로 어느 정도 의존할 수 있을 것으로 기대합니다. 내가 말할 수 있는 한 vgo 의 유일한 옵션은 이러한 종속성과의 호환성 문제로부터 사용자를 보호하려는 경우 모든 업스트림 종속성을 분기하고 이름을 바꾸는 것입니다(또는 동등하게 이를 내 프로젝트에 복사). 나는 그것을 원하는 사람이 없다고 생각합니다.

@willfaught 우리에게 나쁜 버전을 피하기 위해 최대 버전 제한이 사용될 때 빌드를 깨는 것은 성공적인 것으로 간주됩니다! 이것이 우리가 원하는 일입니다.

이야기에서 요점은 이 시나리오에서 vgo가 dep보다 나쁘지 않다는 것입니다. 그의 예 에서 빌드는 dep가 솔루션을 찾을 수 없다는 의미에서 손상되지 않았습니다. dep 가 솔루션을 찾고 해당 솔루션에 잘못된 버전이 포함되어 있어 우리가 피하고 싶었던 것과 동일한 나쁜 상황이 발생한다는 점에서 문제가 있습니다.

훌륭한 예를 보여주는 비디오를 실제로 보아야 하지만 이해/기억하는 요지는 다음과 같습니다.

• 패키지 버전(종속성 요구 사항 포함)은 변경할 수 없습니다.
• 패키지의 기존 종속성에 최대 버전 제한을 추가하려면 패키지의 새 버전을 게시해야 합니다.
• 모든 요구 사항을 충족하기 위해 dep가 패키지의 이전 버전을 선택할 수 있으며, 이 경우 새로운 최대 버전 제한이 없습니다. 이렇게 하면 결국 나쁜 버전을 사용할 수 있습니다.

최대 버전 제외를 추가하자는 제안에 대부분 동의하지만 다음과 같은 걱정이 있습니다. 내 라이브러리에 "gRPC >1.4, <1.8 사용"을 넣은 다음 gRPC 1.9에서 작성자가 "알다시피, Helm은 맞습니다. 1.8에서 주요 변경 사항을 적용했으며 1.9.0에서 이전 동작으로 되돌리고 있습니다." 이제 Helm+gRPC를 가져오려는 사람들은 Helm이 "1.8.0, 1.8.1, 1.8.2를 제외하고 gRPC >1.4를 사용하지만 1.9+는 멋지다"라는 버전을 출시할 때까지 1.9를 사용할 수 없습니다.

즉, gRPC 1.9가 게시될 때까지 호환되지 않는지 여부를 알 수 없기 때문에 exclude grpc 1.8 이면 충분합니다. 이 시점에서 Helm은 제외 목록에 추가할지 여부를 결정할 수 있습니다.

나는 본질적으로 이 공간에 대해 아무것도 모른다. 그러나 여기에서 토론을 읽으면 가장 큰 불일치가 잘못된 사례를 감지하는 방법으로 귀결되는 것처럼 들립니다. 즉, MVS(vgo)와 SAT(dep)는 모두 정상적인 상황을 어느 정도 잘 처리합니다. 동일하지는 않지만 충분히 잘 처리합니다.

SAT는 MVS가 제공하지 않는 기능을 제공합니다. SAT를 사용하여 라이브러리 패키지 P1의 작성자는 "P1에는 P2가 필요하고 P2Version > 1.1 및 P2Version < 1.4에서 작동합니다"라고 선언할 수 있습니다. MVS는 "P1에는 P2가 필요하고 P2Version > 1.1에서 작동"만 선언할 수 있으며 "P2Version < 1.4" 제한을 표현할 수 없습니다. 일반적인 경우에는 중요하지 않습니다. 일부 작업이 P2를 버전 1.4로 업그레이드하려는 경우에만 중요합니다. 이 경우 SAT는 오류를 보고하지만 MVS는 오류를 보고하지 않습니다. MVS를 사용할 때 비호환성이 컴파일 오류가 아닌 경우 오랜 시간이 지난 후 오류가 발생할 수 있습니다.

의심의 여지 없이 SAT 지지자들은 MVS의 다른 주요 문제를 보고 있지만 지금까지는 이것이 제가 이해하는 문제입니다.

제한 표현식 자체에 버전이 지정되어 있는 경우(특정 P1 릴리스의 일부인 경우) 정상적인 이벤트 과정에서 P2 버전 1.4가 릴리스되기 전에 P1 버전 2.2가 "P2Version > 1.1". P2 버전 1.4가 릴리스된 경우에만 P1 작성자가 "P2Version > 1.1 및 P2Version < 1.4"와 함께 비호환성과 릴리스 P1 버전 2.3을 알 수 있습니다. 따라서 P1 버전 2.2를 사용하는 경우 SAT나 MVS 모두 P2를 버전 1.4로 업그레이드하는 데 문제가 있다고 보고하지 않습니다.

즉, P1 릴리스가 P2의 최소 호환 버전을 나열하는 것이 완벽하지만 릴리스가 P2의 최신 버전과 올바르게 작동한다면 릴리스에서 최대 호환 버전을 나열하는 것은 이치에 맞지 않습니다. . 최대 호환 버전은 보수적이어서 더 새롭고 더 나은 버전의 P2가 등장함에 따라 점점 더 잘못되거나, P2가 미래에 호환되지 않는 방식으로 변경되면 릴리스 시점에서 요구 사항을 지정하지 않기 때문에 해당 요구 사항을 지정하지 못할 것입니다. 존재합니다.

따라서 최소 버전 요구 사항 이외의 다른 것을 정의하는 시스템을 갖고 싶다면 해당 요구 사항은 특정 릴리스의 일부가 아니어야 하며 대신 패키지와 관련된 일종의 메타데이터의 일부여야 합니다. 패키지 자체를 업데이트하지 않고 언제든지. 즉, "이 패키지 업데이트" 작업은 "현재 패키지 버전이 호환되는지 확인" 작업과 분리되어야 합니다.

나는 추가로 주장하고 싶습니다. 그리고 이것은 위의 것보다 확실히 더 미약합니다. "현재 패키지 버전이 호환되는지 확인"이 실패하면 일반적으로 문제를 해결하기 위해 어떤 도구도 신뢰하지 않는 것이 현명하지 못합니다. "모든 관련 패키지를 현재 버전으로 업그레이드"하는 간단한 작업으로 호환성 문제를 해결할 수 없다면 생각이 필요합니다. 도구는 그러한 생각을 안내할 수 있지만 일반적으로 그것을 대체할 수는 없습니다. 특히 도구가 자동으로 패키지 다운그레이드를 시작하는 것은 매우 현명하지 못한 것 같습니다.

따라서 우리가 측면에서 생각하면

1. 패키지 비호환성을 설명하는 패키지 메타데이터를 정의하는 방법
2. 이를 기반으로 현재 패키지가 호환되는지 여부를 보고하는 도구

그러면 MVS와 SAT의 주요 차이점 중 일부가 덜 중요해집니다.

Ian님 좋은 말씀 감사합니다. 후속 조치를 위해 일단 버전과 vgo가 설정되면 go 명령이 참조할 수 있는 정보인 패키지에 대한 추가 정보를 기록하는 새로운 godoc.org(다른 이름일 수도 있음)가 필요합니다. 그리고 그 정보 중 일부는 go 명령이 특정 빌드에서 경고 또는 오류로 보고할 수 있는 쌍별 비호환성일 수 있습니다(즉, 피해를 보고하고 해결하여 숨기려고 하지 않음). 그러나 핵심 도구 체인에 모든 버전을 보유하는 것이 첫 번째 단계이며, 최소한의 버전 요구 사항 및 의미론적 가져오기 버전 관리와 함께 이 문제가 승인되었습니다.

최대한 원활하게 착륙할 수 있도록 최선을 다하고 있습니다. 이를 위해서는 기존 패키지의 문제를 해결하기 위해 추가 도구, 더 많은 교육 지원 및 PR이 필요합니다. 이 제안을 수락할 때 모든 것이 차단되었습니다. 전체 접근 방식이 수락되지 않고 진행하는 것이 주제넘은 것처럼 보였기 때문입니다. 그러나 그 제안이 받아들여지고 불확실성이 끝난 지금 작업은 더욱 적극적으로 착륙할 것입니다.

버전 호환성에 대한 외부 정보에 대해서도 같은 생각을 했습니다... 버전 호환성은 전체에 걸쳐 일정해야 하므로 소스 제어에 있을 필요가 없습니다(사실 소스 제어에 있다는 것은 위에서 언급한 바와 같이 확실한 단점입니다). 제안된 대로 MVS의 한 가지 주요 문제인 것처럼 보이기 때문에 이에 대한 제안된 솔루션이 있으면 좋을 것입니다.

토론이 이러한 방향으로 유기적으로 진행되는 것을 보는 것은 굉장합니다. 그것은 내 관심사의 중심적인 추진력이었으며 사람들이 이미 대부분의 방법을 사용했을 때 근본적인 문제를 훨씬 쉽게 설명할 수 있게 해줍니다.

@ianlancetaylor , 이미 릴리스된 버전의 제약 조건 정보를 변경할 수 있어야 한다는 점에 대해 이 관찰을 제대로 이해하고 있다고 생각합니다. @rsc 가 지적했듯이 그러한 서비스는 우리가 회의에서 논의한/제가 제안한 것입니다. godoc.org나 다른 것으로 할 수 있습니다. 하지만 실제로는 별도의 서비스가 필요하지 않고, 없는 것이 더 나을 것이라고 생각합니다. 나는 금요일에 발표한 글 에서 이에 대한 빠른 참조를 만들었습니다. 서비스에는 비호환성 선언이 누구의 경고에 표시되어야 하는지에 대해 대답해야 하는 질문이 있습니다. 이는 ID 처리를 의미하며 선언의 범위를 depgraph의 특정 상황으로 지정하는 방법입니다. 메타데이터 파일 내부에 선언을 유지한다는 것은 우리가 그것에 대해 걱정할 필요가 없다는 것을 의미합니다. 그러나 잠시 후에 더 자세히 설명합니다.

여기에서 정말 중요한 것은 의도한 방식이 아닐 수도 있지만 이 점입니다.

MVS와 SAT의 주요 차이점 중 일부는 덜 중요해집니다.

사람들이 식별하고 있는 문제에 대한 솔루션으로 이 검색을 수행하는 메타 도구(예, SAT 검색)를 제안합니다. MVS가 설명된 대로 진행되는 경우 dep를 변환해야 하는 것과 거의 같습니다. 그리고 여기서 주목해야 할 첫 번째 사항은 검색 도구에 대해 이야기할 정도로 이러한 비호환성에 대해 너무 우려하고 있다면 실제로 우리가 말하는 것은 MVS가 더 큰 알고리즘의 한 단계에 불과하다는 것입니다. grokkability 이점은 창 밖으로 바로 이동합니다.

최소 버전과 현재 버전을 함께 압축할 때 발생하는 기본 정보 손실 문제를 메타 도구로 해결할 수 없기 때문입니다. 그것의 큰 결과는 계단식 롤백 입니다. 즉, 실제로 이 목록의 비호환성을 수정하려고 시도하면 문제와 불필요하게 관련되지 않은 종속성 그래프의 다른 부분을 뒤로 던질 가능성이 매우 높습니다. 그리고 개발자는 다른 사람에게 해롭지 않은 업데이트 전략을 따를 수 없습니다. . (오, 그리고 팬텀 규칙 이지만 일반적으로 MVS 부작용일 뿐입니다).

이것이 내가 MVS가 "목적에 적합하지 않음"과 같은 고차원 도구를 구축하는 데 적합하지 않은 중간 계층이라고 주장한 이유입니다. 사람들은 이러한 비호환성이 발생할 것이라고 믿고 있으므로 MVS는 어려운 문제를 해결하고 더 어렵게 만들고 있습니다.

대신 "비호환성 서비스" 문제를 메타데이터 파일로 다시 통합하면 간단한 쌍별 선언 세트만 사용하여 동일한 효과를 얻을 수 있다고 생각합니다 . (이것은 개념의 초안이지만 점점 더 붙어있는 것 같습니다)

이는 MVS의 일부가 변경되는 것을 수반하지만 MVS는 여전히 거기에 인코딩된 정보 위에서 실행될 수 있습니다. 비호환성이 진정으로 문제가 되고 모든 것을 피하려는 경우에 대부분 유용할 것입니다. 그러나 기본 알고리즘은 MVS처럼 보이는 기준선에서 시작한 다음 터무니없이 오래된 버전으로 이동할 가능성 없이 더 광범위한 검색으로 전환합니다(분명히 MVS 자체는 여전히 검색으로 간주되어야 함).

(참고로 저는 이번 주에 휴가를 가므로 다음 주말까지 답장을 보내지 않습니다.)

@sdboyer

이 검색을 수행하는 메타 도구의 제안 - 예, SAT 검색입니다.

더 자세하게 얘기해 주 시겠어요? 인용하신 문장은 Ian 이 선택한 버전이 호환되는지 여부 를 보고하는 도구를 제안한 직후입니다. 제가 아는 한, 이것이 여기에서 제안된 주요 대안입니다(위에서 의도한 것입니다). 그 문제는 가장 확실히 검색이 아니며 사소하고 SAT를 풀 필요가 없습니다(이는 주어진 값 집합에 대한 부울 공식을 평가할 뿐이며 만족하는 값을 찾으려고 하지 않습니다).

맞습니다. 공식에 호환되지 않는 것으로 알려진 값이 있다고 보고하는 것만으로는 SAT를 풀 필요가 없습니다. 그러한 값이 없는 결과를 찾는 프로세스를 지원하는 도구와 같이 이를 기반으로 하는 조치를 취하는 것입니다.

내가 그 문장을 인용한 이유는 사람들이 수색을 항상 필요하다고 받아들였기 때문이 아니라 그러한 조건을 보고하는 것이 중요하다고 믿는다면 그러한 시나리오에 직면할 가능성이 높다고 믿기 때문입니다.

문제는 일단 해당 사례를 해결하는 것의 타당성과 중요성이 확립되면 사람들이 "MVS 위에서 모든 검색 작업을 수행할 수 있으며 괜찮을 것"이라고 잘못된 점프를 하는 것처럼 보입니다. 우리는 할 수 있지만 MVS가 의도적으로 차단하는 유용한 가능한 경로 때문에 그러한 시도를 처리하기가 훨씬 더 까다로워집니다.

2018년 5월 28일 오후 4:02:13 EDT, Axel Wagner [email protected] 쓴 글:

@sdboyer

이 검색을 수행하는 메타 도구의 제안 - 그렇습니다.
수능 검색

더 자세하게 얘기해 주 시겠어요? 인용하신 문장은 Ian 바로 뒤에 있습니다.
선택한 버전이 다음과 같은지 보고하는 도구 제안호환 가능 - 내가 아는 한, 그것이 주요
여기에 제안된 대안이 있습니다(확실히 위에서 의도한 것입니다).
그 문제는 가장 확실히 검색이 아니며 사소하고
SAT를 풀 필요가 없습니다(단지 부울 공식을 평가할 뿐입니다.
주어진 값 집합에 대해 만족하는 값을 찾으려고 하지 않음).

--
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/golang/go/issues/24301#issuecomment -392595150

내가 그 문장을 인용한 이유는 사람들이 수색을 항상 필요하다고 받아들였기 때문이 아니라 그러한 조건을 보고하는 것이 중요하다고 믿는다면 그러한 시나리오에 직면할 가능성이 높다고 믿기 때문입니다.

명확히 하기 위해: 이러한 방식으로 상한선을 개조하자는 제안은 제기된 우려에 순전히 반응하고 그것이 수행될 수 있음을 보여줍니다(MVS가 근본적으로 목적에 부적합하다는 주장에 비판적으로 질문하기 위해). 그 양보와 기꺼이 타협하려는 의지를 우리가 당신이 옳았다고 생각한다는 증거로 받아들이는 것은 약간 불공평해 보입니다.

나에게 그 주장(MVS는 부적합하고 본질적으로 잘못된 방향으로 돌이킬 수 없는 단계)은 내가 개인적으로 도전하는 것이고 내가 당신의 주장을 읽고 있는 렌즈입니다. 이러한 주장 중 하나는 비호환성을 선언할 수 있고 버전 선택 알고리즘이 발생할 때 실패하도록 할 수 있는 기능이라는 것입니다. 또 다른 공정한 주장은 문제가 발생하면 알고리즘이 우리를 위해 문제를 해결할 수 있게 하는 것이 좋을 것입니다(실제로 SAT 솔버가 필요함).

그러나 나는 그것이 타당하고 공정한 우려라고 생각하지만 MVS가 근본적으로 부적합하다는 것을 증명하는 기준을 통과했다고 생각하지 않습니다. 나는 여전히 MVS를 출발점으로 삼아 훌륭하고 중요한 기능을 제공한다고 믿습니다. 그리고 이러한 우려가 실제로 상당한 고통을 야기하는 것으로 판명 되면 순수한 실패로 상한을 추가하는 것( go.mod 의 일부로 또는 별도의 서비스로)을 추가하는 것부터 반복할 수 있는 많은 방법이 있습니다. 어느 시점에서 전체 SAT 솔버 및 잠금 파일을 추가하는 것을 포함합니다. 즉, 나는 그런 일이 일어날 것이라는 것에 동의하지만 a) 그것이 당신이 예상하는 것만큼 고통을 일으키지 않을 것이라고 (아마도 순진하게) 낙관적이며 b) 우리가 MVS로 시작할 때도 해결할 수 있는 문제입니다.

호환성을 결정하는 소스 제어 외부의 무언가가 MVS 시스템의 결정성을 변경할 것이라고 생각합니다. 한 라이브러리에 foo >= 1.5.0이 제약 조건으로 있고 다른 라이브러리에 foo >= 1.6.0이 있는 경우. 그런 다음 이 두 개를 바이너리에 넣고 1.6.0을 선택합니다. MVS에서는 이것이 반복 가능한 빌드에 필요한 전부입니다. 항상 1.6을 선택합니다

그러나 외부 호환성을 믹스에 추가하면 첫 번째 라이브러리가 1.6과 호환되지 않는다고 업데이트할 수 있습니다. 그러면 코드가 변경되지 않았음에도 알고리즘이 1.7을 선택합니다... 즉, 다음이 필요합니다. 파일을 다시 잠급니다.

참고로 락파일은 나쁘지 않다고 생각합니다. 빌드해야 하는 정확한 목록이 있는 것이 좋습니다. 그리고 빠르게 해야 합니다. 마법의 논리가 필요하지 않습니다.

@natefinch 외부 호환성 도구가 v1.6.0이 호환되지 않는 것으로 표시되어 응용 프로그램의 go.mod 파일이 v1.7.0이 필요하도록 업데이트된 경우 잠금 파일이 필요하지 않습니다. go.mod 파일에 v1.7.0이 존재하기 때문에 작성자는 v1.7.0이 사용되는 이유와 해당 정보가 독자에게 유용하다는 설명을 추가할 수도 있습니다.

@leighmcculloch , 앱의 파일이 업데이트되면 다른 빌드이며 "lockfile 없이 재현 가능한 빌드" 문제의 범위를 완전히 벗어납니다.

지식이 어떻게 발전하는지 반영하기 위해 대역 외 호환성 정보가 제안됩니다. 릴리스 당시에는 비호환성이 알려져 있지 않았지만 그 다음에는 명백해졌으며 이미 릴리스된 버전에 대한 추가 정보가 게시됩니다. IMHO 정의에 따르면 이 접근 방식은 종속성을 가져오는 방식을 변경합니다. 그렇지 않으면 왜 이것이 비호환성 정보를 전혀 추출하지 않습니까?

@redbaron @natefinch

비호환성 정보의 요점은 라이브러리 작성자가 사용자에게 비호환성 정보를 전달하는 것입니다. 해당 정보가 빌드 시 사용되는지 릴리스 시 사용되는지는 다른 질문입니다.

vgo의 경우 현재 아이디어는 경고(또는 잠재적으로 삐걱거림)만 표시하는 것입니다. 그러나 특히 사용되는 버전 선택에 영향을 미치지 않도록 해야 합니다(SAT를 풀어야 하기 때문에). 따라서 실제로는 중요하지 않습니다. 둘 중 하나 또는 둘 모두에서 사용할 수 있으며 반복성¹의 속성을 유지하면서 의무를 잘 수행할 것입니다.

기본적으로 이 정보는 릴리스 시에만 사용되며 빌드 시 사용되는 잠금 파일에 기록됩니다. 따라서 적어도 vgo 대 dep에 관한 문제에 관해서는 릴리스 시간 사용을 "충분히" 사용하는 것을 고려하고 있는 것 같습니다.

나는 여전히 우리가 지금 당장 그 질문들에 실제로 답해야 한다고 생각하지 않습니다.

[1] 개인적으로 사용자가 경고가 실행 가능한지 여부를 결정할 필요가 없어야 하기 때문에 릴리스 시 사용하고 빌드 시 -v 를 사용하는 경우에만 사용하는 것이 더 낫다고 주장합니다.

@rsc 는 다음과 같이 썼습니다.

후속 조치를 위해 일단 버전과 vgo가 설정되면 go 명령이 참조할 수 있는 정보인 패키지에 대한 추가 정보를 기록하는 새로운 godoc.org(다른 이름일 수도 있음)가 필요합니다. 그리고 그 정보 중 일부는 go 명령이 특정 빌드에서 경고 또는 오류로 보고할 수 있는 쌍별 비호환성일 수 있습니다(즉, 피해를 보고하고 해결하여 숨기려고 하지 않음).

쌍별 비호환성 기록이 필요한지 궁금합니다. 현재 내가 보는 방식은 모듈 A@vN 과 모듈 B@vM 사이의 비호환성은 실제로 B가 L < M인 일부 버전 vL에서 호환되지 않는 변경을 했기 때문입니다.

모듈 B가 호환되지 않는 변경을 하지 않았다면 모듈 A에는 버그가 있을 뿐입니다. 그렇다면 문제는 A와 B의 쌍이 아니라 B ​​자체에 관한 것입니다.

따라서 ISTM은 모듈 메타데이터의 모든 공개 저장소가 이전 버전의 모듈과의 비호환성 만 기록할 수 있으므로 문제를 더 다루기 쉽게 만들 수 있습니다. 이러한 비호환성 보고서는 버그 보고서와 매우 유사하지만 버전이 게시되면 변경할 수 없기 때문에 해결할 수는 없습니다.

모듈 버전을 업그레이드할 때 go 도구는 메타데이터를 고려하고 현재 선택한 버전과 호환되지 않는 버전을 고려하지 않을 수 있습니다. 나는 이것이 SAT를 풀 필요를 피 한다고 생각 합니다. 또한 주어진 모듈에 너무 많은 비호환성 보고서가 있다고 판단하여 종속성으로 추가하는 것을 거부할 수 있습니다.

( module , oldVersion , newVersion , description ) 형식의 튜플 세트로 충분할 수 있습니다.

go 도구는 메타데이터를 고려하고 현재 선택한 버전과 호환되지 않는 버전은 고려하지 않을 수 있습니다.

물론, 이것은 새로운 버전이 기존 모듈의 일부가 아니기 때문에 여러 종속성을 추가할 때 작동하지 않습니다. 종속성은 비교적 드물게 추가 되어야 하기 때문에 중요한 AFAICS는 아닙니다.

나는 go release 이 토론의 "충분히 똑똑한 컴파일러" 가 되고 있다고 걱정합니다. 사용자는 Go 1.11/12의 go release 에서 구체적으로 무엇을 기대할 수 있습니까? 나는 그것이 MVS/SIV에 대한 합리적인 기대가 무엇인지에 대한 차이를 만든다고 생각합니다.

많은 분들이 Go와 특히 이 제안에 가져온 에너지에 감사드립니다.

제안 프로세스의 첫 번째 목표는 "명확한 답변과 함께 제안이 적절하고 공정하며 시기적절하고 기록된 평가를 받을 수 있도록 하는 것"입니다. 이 제안은 오랫동안 논의되었고 우리는 토론 요약을 발표했습니다. 6주 동안 많은 토론 끝에 내가 제안서를 작성했기 때문에 중재자 역할을 하는 제안 검토 위원회가 제안을 수락했습니다.

단일 GitHub 문제는 광범위한 토론을 하기 어려운 곳입니다. GitHub에는 대화의 여러 가닥에 대한 스레딩이 없고 더 이상 모든 주석을 표시하지도 않기 때문입니다. 이와 같은 토론이 작동하는 유일한 방법은 토론 요약을 적극적으로 큐레이션하는 것입니다. 제안이 받아들여질 무렵에는 요약조차 다루기 어려워졌습니다.

이제 제안이 수락되었으므로 이 문제는 더 이상 토론하기에 적합하지 않으며 요약을 더 이상 업데이트하지 않습니다. 대신, 귀하가 겪고 있는 문제에 대한 새롭고 구체적인 문제를 제출하거나 변경 사항에 대한 구체적인 제안을 제출하여 각 특정 주제에 대해 집중적인 토론을 할 수 있도록 하십시오. 이러한 새로운 문제에는 "x/vgo:"를 접두어로 붙이십시오. 새 호의 텍스트에서 #24301을 언급하면 ​​다른 사람들이 찾을 수 있도록 여기에서 상호 참조됩니다.

마지막 요점은 제안을 수락한다는 것은 프로토타입 구현 버그 등이 아니라 아이디어를 수락하는 것을 의미한다는 것입니다. 아직 해결해야 할 세부 사항과 수정해야 할 버그가 있으며 계속해서 함께 할 것입니다.

모든 도움에 다시 한 번 감사드립니다.

수행해야 할 작업이 더 있지만( modules 레이블 참조) 이 문제에서 제안한 초기 모듈 구현이 메인 트리에 커밋되었으므로 이 문제를 닫습니다.