Bazel 모듈

Bazel 모듈은 여러 버전으로 구성될 수 있는 Bazel 프로젝트이며, 각 버전은 종속된 다른 모듈에 대한 메타데이터를 게시합니다. 이는 Maven 아티팩트, npm 패키지, Go 모듈, Cargo 크레이트와 같은 다른 종속 항목 관리 시스템의 익숙한 개념과 유사합니다.

모듈의 저장소 루트에 MODULE.bazel 파일이 있어야 합니다. 이 파일은 모듈의 매니페스트로, 모듈의 이름, 버전, 직접 종속 항목 목록 및 기타 정보를 선언합니다. 기본적인 예는 다음과 같습니다.

module(name = "my-module", version = "1.0")

bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")

MODULE.bazel 파일에서 사용 가능한 지시어 전체 목록을 참고하세요.

모듈 확인을 실행하기 위해 Bazel은 루트 모듈의 MODULE.bazel 파일을 읽은 다음 전체 종속 항목 그래프를 찾을 때까지 Bazel 레지스트리에서 종속 항목의 MODULE.bazel 파일을 반복적으로 요청합니다.

그런 다음 기본적으로 Bazel은 사용할 각 모듈의 한 버전을 선택합니다. Bazel은 저장소가 있는 각 모듈을 나타내며 레지스트리를 다시 참조하여 각 저장소를 정의하는 방법을 알아봅니다.

버전 형식

Bazel은 다양한 생태계를 보유하고 있으며 프로젝트는 다양한 버전 관리 스키마를 사용합니다. 지금까지 가장 인기 있는 것은 SemVer이지만, 버전이 날짜 기반인 Abseil과 같이 다양한 체계를 사용하는 유명한 프로젝트도 있습니다(예: 20210324.2).

이러한 이유로 Bzlmod는 SemVer 사양의 보다 완화된 버전을 사용합니다. 차이점은 다음과 같습니다.

SemVer에서는 버전의 'release' 부분이 3개의 세그먼트(MAJOR.MINOR.PATCH)로 구성되도록 규정합니다. Bazel에서는 이 요구사항이 완화되어 세그먼트 수가 제한 없이 허용됩니다.
SemVer에서 'release' 부분의 각 세그먼트는 숫자만 사용해야 합니다. Bazel에서는 문자도 허용하도록 느슨해졌으며 비교 시맨틱은 '출시 전' 부분의 '식별자'와 일치합니다.
또한 주 버전, 부 버전 및 패치 버전 증가의 의미 체계는 적용되지 않습니다. 하지만 이전 버전과의 호환성을 표시하는 방법에 관한 자세한 내용은 호환성 수준을 참고하세요.

유효한 SemVer 버전은 유효한 Bazel 모듈 버전입니다. 또한 두 개의 SemVer 버전 a와 b는 Bazel 모듈 버전과 비교할 때 동일한 보존 조치가 있는 경우에만 a < b를 비교합니다.

버전 선택

버전이 지정된 종속 항목 관리 공간의 핵심 요소인 Diamond 종속 항목 문제를 생각해 보세요. 종속 항목 그래프가 있다고 가정해 보겠습니다.

       A 1.0
      /     \
   B 1.0    C 1.1
     |        |
   D 1.0    D 1.1

어떤 D 버전을 사용해야 하나요? 이 문제를 해결하기 위해 Bzlmod는 Go 모듈 시스템에 도입된 최소 버전 선택(MVS) 알고리즘을 사용합니다. MVS는 모듈의 모든 새 버전이 이전 버전과 호환된다고 가정하므로 종속 항목에 의해 지정된 가장 높은 버전을 선택합니다 (이 예에서는 D 1.1). '최소'라고 하는 이유는 D 1.1가 요구사항을 충족할 수 있는 가장 초기 버전이기 때문입니다. D 1.2 이상이 존재하더라도 선택하지 않습니다. MVS를 사용하면 고충실도와 재현 가능한 버전 선택 프로세스가 생성됩니다.

양키 버전

레지스트리는 특정 버전을 피해야 하는 경우(예: 보안 취약점으로 인해) 양크됨으로 선언할 수 있습니다. Bazel이 양각된 모듈 버전을 선택하면 오류가 발생합니다. 이 오류를 수정하려면 양크되지 않은 최신 버전으로 업그레이드하거나 --allow_yanked_versions 플래그를 사용하여 야크 처리된 버전을 명시적으로 허용합니다.

호환성 수준

Go에서는 이전 버전과 호환되지 않는 모듈 버전을 별도의 모듈로 취급하기 때문에 이전 버전과의 호환성에 대한 MVS의 가정이 작동합니다. 이는 SemVer 측면에서 A 1.x와 A 2.x가 별개의 모듈로 간주되며 결정된 종속 항목 그래프에 공존할 수 있음을 의미합니다. 결과적으로 Go의 패키지 경로에 주 버전을 인코딩하여 컴파일 시간 또는 연결 시간 충돌이 없습니다.

그러나 Bazel은 이러한 보장을 제공할 수 없으므로 이전 버전과 호환되지 않는 버전을 감지하려면 '주 버전' 번호가 필요합니다. 이 숫자를 호환성 수준이라고 하며, module() 지시문의 각 모듈 버전에 의해 지정됩니다. Bazel은 이 정보를 통해 해결된 종속 항목 그래프에 호환성 수준이 다른 동일한 모듈의 버전이 존재하는 것을 감지할 때 오류를 발생시킬 수 있습니다.

재정의

MODULE.bazel 파일에 재정의를 지정하여 Bazel 모듈 해상도 동작을 변경합니다. 루트 모듈의 재정의만 적용됩니다. 모듈을 종속 항목으로 사용하면 재정의가 무시됩니다.

각 재정의는 특정 모듈 이름에 지정되며 종속 항목 그래프의 모든 버전에 영향을 미칩니다. 루트 모듈의 재정의만 적용되지만 루트 모듈이 직접 의존하지 않는 전이 종속 항목에 적용될 수 있습니다.

단일 버전 재정의

single_version_override는 다양한 용도로 사용됩니다.

version 속성을 사용하면 종속 항목 그래프에서 요청된 종속 항목 버전과 관계없이 종속 항목을 특정 버전에 고정할 수 있습니다.
registry 속성을 사용하면 일반적인 레지스트리 선택 프로세스를 따르는 대신 특정 레지스트리에서 이 종속 항목을 가져오도록 할 수 있습니다.
patch* 속성을 사용하면 다운로드한 모듈에 적용할 패치 집합을 지정할 수 있습니다.

이러한 속성은 모두 선택사항이며 서로 조합하여 사용할 수 있습니다.

다중 버전 재정의

multiple_version_override를 지정하여, 동일한 모듈의 여러 버전이 해결된 종속 항목 그래프에 공존할 수 있습니다.

모듈에 허용되는 버전의 명시적인 목록을 지정할 수 있습니다. 이 목록은 해결 전에 종속 항목 그래프에 모두 있어야 합니다. 허용된 각 버전에 따라 일부 전이 종속 항목이 있어야 합니다. 해결 후에는 허용된 버전의 모듈만 남는 반면, Bazel은 모듈의 다른 버전을 동일한 호환성 수준에서 허용되는 가장 가까운 버전으로 업그레이드합니다. 동일한 호환성 수준에서 허용되는 상위 버전이 없으면 Bazel이 오류를 발생시킵니다.

예를 들어 해결 전에 종속 항목 그래프에 버전 1.1, 1.3, 1.5, 1.7, 2.0이 있고 주 버전이 호환성 수준인 경우:

1.3, 1.7, 2.0를 허용하는 다중 버전 재정의를 사용하면 1.1가 1.3로 업그레이드되고 1.5는 1.7로 업그레이드되며 다른 버전은 동일하게 유지됩니다.
1.5 및 2.0를 허용하는 다중 버전 재정의는 오류가 발생합니다. 1.7에는 업그레이드할 동일한 호환성 수준의 상위 버전이 없기 때문입니다.
1.9 및 2.0를 허용하는 다중 버전 재정의는 오류를 야기합니다. 해결 전에 1.9가 종속 항목 그래프에 없기 때문입니다.

또한 사용자는 단일 버전 재정의와 유사하게 registry 속성을 사용하여 레지스트리를 재정의할 수도 있습니다.

비등록처 재정의

비 레지스트리 재정의는 버전 확인에서 모듈을 완전히 삭제합니다. Bazel은 레지스트리에서 이러한 MODULE.bazel 파일을 요청하는 것이 아니라 저장소 자체에서 요청합니다.

Bazel은 다음과 같은 비레지스트리 재정의를 지원합니다.

Bazel 모듈을 나타내지 않는 저장소 정의

bazel_dep를 사용하면 다른 Bazel 모듈을 나타내는 저장소를 정의할 수 있습니다. Bazel 모듈을 나타내지 않는 저장소를 정의해야 하는 경우가 있습니다. 예를 들어 데이터로 읽을 일반 JSON 파일이 포함된 저장소를 정의할 수 있습니다.

이 경우 use_repo_rule 지시어를 사용하여 저장소 규칙을 호출하여 저장소를 직접 정의할 수 있습니다. 이 저장소는 저장소가 정의된 모듈에만 표시됩니다.

내부적으로 이 기능은 모듈 확장과 동일한 메커니즘을 사용하여 구현되므로 저장소를 더 유연하게 정의할 수 있습니다.

저장소 이름 및 엄격한 deps

bazel_dep 지시어의 repo_name 속성에 달리 명시되지 않는 한 직접 종속 항목에 모듈을 지원하는 저장소의 명확한 이름은 기본적으로 모듈 이름으로 설정됩니다. 즉, 모듈은 직접 종속 항목만 찾을 수 있습니다. 이렇게 하면 전이 종속 항목의 변경으로 인한 우발적인 중단을 방지할 수 있습니다.

모듈을 지원하는 저장소의 표준 이름은 전체 종속 항목 그래프에 여러 버전의 모듈이 있는지 여부에 따라 module_name~version(예: bazel_skylib~1.0.3) 또는 module_name~(예: bazel_features~)입니다. 표준 이름 형식은 개발자가 사용해야 하는 API가 아니며 언제든지 변경될 수 있습니다.multiple_version_override 표준 이름을 하드 코딩하는 대신 지원되는 방법을 사용하여 Bazel에서 직접 가져옵니다. * BUILD 및 .bzl 파일의 경우 저장소의 명확한 이름으로 지정된 라벨 문자열에서 구성된 Label 인스턴스에 Label.repo_name를 사용합니다. 예: Label("@bazel_skylib").repo_name. * 실행 파일을 찾을 때 $(rlocationpath ...) 또는 @bazel_tools//tools/{bash,cpp,java}/runfiles의 실행 파일 라이브러리 중 하나를 사용하거나 @rules_foo//foo/runfiles 규칙 세트 rules_foo의 경우 실행 파일 라이브러리 중 하나를 사용합니다. * IDE 또는 언어 서버와 같은 외부 도구에서 Bazel과 상호작용할 때는 bazel mod dump_repo_mapping 명령어를 사용하여 명확한 저장소 이름에서 지정된 저장소 집합의 표준 이름으로의 매핑을 가져옵니다.

모듈 확장 역시 모듈의 가시적 범위에 추가 저장소를 도입할 수 있습니다.