Bazel 모듈

<ph type="x-smartling-placeholder"></ph> 문제 신고 소스 보기 1박 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Bazel 모듈은 각각 종속된 다른 모듈에 관한 메타데이터를 게시합니다. 이것은 종속 항목 관리 시스템의 익숙한 개념과 유사합니다. Maven 아티팩트, npm 패키지, Go 모듈 또는 Cargo 크레이트

모듈의 저장소 루트에 MODULE.bazel 파일이 있어야 합니다( WORKSPACE 파일). 이 파일은 이름을 선언하는 모듈의 매니페스트이며 직접 종속 항목 목록 및 기타 정보가 포함됩니다. 기본 예:

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 파일을 열고 종속 항목의 모든 종속 항목을 반복적으로 MODULE.bazel 파일을 업로드하여 Bazel 레지스트리에서 전체 종속 항목 그래프를 검색합니다.

그러면 기본적으로 Bazel이 각 모듈의 버전 하나를 선택합니다. 있습니다. Bazel은 저장소로 각 모듈을 나타내고 레지스트리에 문의합니다. 각 저장소를 정의하는 방법을 알아보겠습니다.

버전 형식

Bazel은 다양한 생태계를 보유하고 있으며 프로젝트에서 다양한 버전 관리 체계를 사용합니다. 이 SemVer가 가장 인기 있지만 다음과 같은 다양한 체계를 사용하여 Abseil, 버전은 날짜 기반입니다(예: 20210324.2).

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

  • SemVer는 “릴리스” 버전의 부분은 3으로 구성되어야 함 세그먼트: MAJOR.MINOR.PATCH. Bazel에서는 이 요구사항이 완화되어 세그먼트가 허용되지 않습니다.
  • SemVer에서 'release' 부분은 숫자로만 이루어져야 합니다. Bazel에서는 문자도 허용하도록 느슨하게 되어 있고, 시맨틱스는 '식별자'와 'prerelease' 있습니다.
  • 또한 주 버전, 부 버전 및 패치 버전 증가의 의미 체계는 적용되지 않습니다. 자세한 내용은 호환성 수준을 이전 버전과의 호환성을 나타내는 방법에 대한 자세한 내용을 참조하세요.

유효한 SemVer 버전은 모두 유효한 Bazel 모듈 버전입니다. 또한 SemVer 버전 a 및 b는 다음과 같은 경우에 동일한 보존 조치가 적용된 경우에만 a < b를 비교합니다. Bazel 모듈 버전과 비교됩니다

버전 선택

버전이 지정된 종속 항목의 핵심인 다이아몬드 종속 항목 문제 고려 관리할 수 있습니다. 종속 항목 그래프가 있다고 가정해 보겠습니다.

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

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

Yanked 버전

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

호환성 수준

Go에서 이전 버전과의 호환성에 관한 MVS의 가정은 이전 버전과 호환되지 않는 모듈 버전을 별도의 모듈로 그룹화합니다. 인코더-디코더 아키텍처를 SemVer: 즉, A 1.x와 A 2.x는 별개의 모듈로 간주되며 확인된 종속 항목 그래프에 공존하는 것을 확인할 수 있습니다 이는 결국 주 버전을 Go의 패키지 경로에 인코딩해야 하므로 컴파일 시간 또는 링크 시간 충돌이 있을 때 발생합니다.

그러나 Bazel은 이러한 보장을 제공할 수 없으므로 '주 버전'이 필요합니다. 번호 1개를 사용하여 이전 버전과 호환되지 않는 버전을 감지합니다. 이 번호는 호환성 수준이며, 각 모듈 버전에 의해 module() 지시문 Bazel은 이 정보를 사용하여 동일한 모듈의 호환성 수준이 다른 버전을 감지합니다. 확인된 종속 항목 그래프에 있는지 확인합니다

재정의

MODULE.bazel 파일에 재정의를 지정하여 Bazel 동작 변경 모듈 해상도 루트 모듈의 재정의만 적용됩니다. 모듈이 다음과 같은 경우 종속 항목으로 사용되는 경우 해당 재정의는 무시됩니다.

각 재정의는 특정 모듈 이름에 지정되며 종속 항목 그래프에서 버전을 확인할 수 있습니다. 루트 모듈의 재정의만 루트 모듈이 제공하지 않는 전이 종속 항목일 수 있습니다. 달라진다는 사실을 기억하실 겁니다

단일 버전 재정의

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

  • version 속성을 사용하면 종속 항목을 특정 버전( 종속 항목 그래프입니다.
  • registry 속성을 사용하면 이 종속 항목을 특정 레지스트리에 등록하여 일반 레지스트리를 따르는 것이 선택 프로세스에서 시작됩니다.
  • patch* 속성을 사용하면 적용할 패치 집합을 지정할 수 있습니다. 다운로드할 수 있습니다.

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

여러 버전 재정의

multiple_version_override 는 같은 모듈의 여러 버전이 클러스터에 공존하도록 지정할 수 있습니다. 해결된 종속 항목 그래프를 확인합니다.

모듈에 허용되는 버전의 명시적 목록을 지정할 수 있습니다. 해결 전에 종속 항목 그래프에 모두 존재해야 합니다. 일부 전이 종속성을 사용합니다. 후(After) 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를 사용하여 레지스트리를 재정의할 수 있습니다. 단일 버전 재정의와 비슷하게 작동합니다.

레지스트리 외 재정의

비 레지스트리 재정의는 버전 확인에서 모듈을 완전히 삭제합니다. 바젤 레지스트리에서 MODULE.bazel 파일을 요청하지 않고 대신 변경할 수 있습니다

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

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

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

이 경우 use_repo_rule 지시어를 사용하여 저장소를 직접 정의합니다. 코드를 생성할 수 있습니다 이 저장소는 해당 저장소가 속한 모듈에만 표시됩니다. 정의합니다.

내부적으로는 모듈과 동일한 메커니즘을 사용하여 구현됩니다. 확장 프로그램도 제공합니다. 있습니다

저장소 이름 및 엄격한 deps

애플리케이션을 지원하는 저장소의 명확한 이름 모듈의 직접적인 종속 항목에 대한 기본값은 모듈 이름이 됩니다. 단, bazel_dep의 repo_name 속성 다르게 표시됩니다 이는 모듈이 종속 항목이 포함됩니다 이렇게 하면 기기의 변경사항으로 인한 우발적인 파손을 방지할 수 있습니다. 전이 종속 항목이 포함됩니다.

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

모듈 확장을 통해 추가 저장소 도입 가능 모듈의 가시적 범위로 설명할 수 있습니다.