검색
검색

상대 경로를 사용하지 않고 다른 규칙에서 bazel 규칙의 출력에 액세스하려면 어떻게해야합니까?

debugcn 에 게시 Dev
12
user2515975

Bazel을 사용하여 dhall-kubernetes를 기반으로 dhall 프로그램을 컴파일하여 Kubernetes YAML 파일을 생성하려고합니다.

기본적인에게 달 컴파일 간단한 bazel 매크로를 사용에게 달-는 Kubernetes없이 괜찮 작동합니다.

dhall의 종속성 해결을 사용하여 dhall-kubernetes를 다운로드하는 예제를 만들었습니다 . 여기를 참조 하십시오 . 이것은 또한 작동하지만 매우 느리고 (dhall이 각 원격 파일을 개별적으로 다운로드하기 때문에 생각합니다) bazel 규칙 실행에 네트워크 종속성을 도입하므로 피하고 싶습니다.

내가 선호하는 접근 방식은 Bazel을 사용하여 dhall-kubernetes의 아카이브 릴리스 버전을 다운로드 한 다음 규칙이 로컬로 액세스하도록하는 것입니다 ( 여기 참조 ). 내 솔루션에는 dhall-kubernetes를 참조하기위한 examples / k8s 패키지의 Prelude.dhall 및 package.dhall의 상대 경로가 필요합니다. 작동하는 동안 Bazel에서 내부적으로 사용하는 폴더 구조에 대한 특별한 지식이 필요하여 Bazel 샌드 박스가 전복되는 것이 우려됩니다. 더 좋은 방법이 있습니까?

Prelude.dhall :

../../external/dhall-kubernetes/1.17/Prelude.dhall

작업 공간 :

workspace(name = "dhall")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

DHALL_KUBERNETES_VERSION = "4.0.0"

http_archive(
    name = "dhall-kubernetes",
    sha256 = "0bc2b5d2735ca60ae26d388640a4790bd945abf326da52f7f28a66159e56220d",
    url = "https://github.com/dhall-lang/dhall-kubernetes/archive/v%s.zip" % DHALL_KUBERNETES_VERSION,
    strip_prefix = "dhall-kubernetes-4.0.0",
    build_file = "@//:BUILD.dhall-kubernetes",
)

BUILD.dhall-kubernetes :

package(default_visibility=['//visibility:public'])

filegroup(
    name = "dhall-k8s-1.17",
    srcs = glob([
        "1.17/**/*",
    ]),
)

examples / k8s / BUILD :

package(default_visibility = ["//visibility:public"])

genrule(
    name = "special_ingress",
    srcs = ["ingress.dhall",
            "Prelude.dhall",
            "package.dhall",
        "@dhall-kubernetes//:dhall-k8s-1.17"
    ],
    outs = ["ingress.yaml"],
    cmd = "dhall-to-yaml --file $(location ingress.dhall) > $@",
    visibility = [
        "//visibility:public"
    ]
)
가브리엘 곤잘레스

dhall"오프라인"빌드를 수행 하도록 계측하는 방법이 있습니다. 즉, 패키지 관리자가 Dhall 종속성을 가져 오는 대신 모든 Dhall 종속성을 가져옵니다.

사실, 저는 Nixpkgs에 대해 정확히 다음과 같이 구현했습니다. Bazel로 번역 할 수 있습니다.

높은 수준의 설명

기본 트릭은 Dhall의 가져 오기 시스템의 기능을 활용하는 것입니다. 즉, 의미 론적 무결성 검사 (즉, "의미 적 해시")로 보호되는 패키지가 캐시되면 Dhall은 패키지를 가져 오는 대신 캐시를 사용합니다. 이러한 방식으로 종속성을 주입하여 패키지 관리자가 Dhall의 원격 가져 오기를 우회하도록이 트릭을 구축 할 수 있습니다.

여기에서 Nix 관련 로직을 찾을 수 있습니다.

...하지만 나는 그것이 패키지 관리자 독립적 인 방식으로 어떻게 작동하는지 설명하려고 노력할 것입니다.

패키지 구조

첫째, Nix를 사용하여 구축 된 Dhall "패키지"의 최종 제품은 다음 구조의 디렉토리입니다.

$ nix-build --attr 'dhallPackages.Prelude."13.0.0"'
…

$ tree result

이 디렉토리의 내용은 다음과 같습니다.

  • ./cache/dhall/1220XXX…XXX

    단일 빌드 제품을 포함하는 Dhall의 유효한 캐시 디렉토리 : 해석 된 Dhall 표현식의 이진 인코딩.

    를 사용하여 이러한 이진 파일을 만들 수 있으며 위 의 내용을 명령을 사용하여 얻을 수있는 식 의 인코딩 dhall encode으로 대체하여 파일 이름을 계산할 수 있습니다 .XXX…XXXsha256dhall hash

  • ./binary.dhall

    표현식을 포함하는 편리한 Dhall 파일 missing sha256:XXX…XXX. 이 표현식 해석은 해시와 일치하는 표현식 sha256:XXX…XXX이 이미 캐시 된 경우에만 성공합니다 .

    이 파일은 binary.dhall"이진"패키지 배포에 해당하는 Dhall이기 때문에 호출 됩니다. 즉, 가져 오기는 이진 캐시에서만 가져올 수 있으며 소스에서 가져 와서 해석 할 수 없습니다.

  • 선택 과목: ./source.dhall

    이것은 캐시 된 표현식에 해당하는 완전히 αβ 정규화 된 표현식을 포함하는 파일입니다. 기본적으로 최상위 패키지를 제외한 모든 패키지에 대해 생략해야합니다. 이는 내부에 저장된 동일한 표현식을 포함하기 ./cache/1220XXX…XXX때문입니다. 이진 인코딩이 더 간결하기 때문입니다.

    이 파일은 ./source.dhall동일한 결과를 생성하는 유효한 소스 코드를 포함하는 "소스"패키지 배포에 해당하는 Dhall이기 때문에 호출 됩니다.

사용자 인터페이스

패키지를 빌드하는 함수는 네 가지 인수를 사용합니다.

  • 패키지 이름

    이것은 빌드에 중요하지 않습니다. 모든 Nix 패키지에는 사람이 읽을 수있는 이름이 있어야하므로 이름을 지정하는 것입니다.

  • 빌드에 대한 종속성

    이러한 각 종속성은 위에서 설명한 것과 같은 디렉터리 트리를 생성하는 빌드 제품입니다 (예 : ./cache디렉터리, ./binary.dhall파일 및 선택적 ./source.dhall파일).

  • Dhall 표현

    이것은 임의의 Dhall 소스 코드 일 수 있습니다. 단 한 가지주의 사항이 있습니다. 표현식에 의해 전 이적으로 참조되는 모든 원격 가져 오기는 무결성 검사로 보호되어야하며 이러한 가져 오기는이 Dhall 패키지에 대한 종속성 중 하나와 일치해야합니다 (가져 오기가 다음을 통해 충족 될 수 있도록 URL을 가져 오는 Dhall 런타임 대신 캐시)

  • 기본적으로 ./source.dhall파일 을 유지할지 여부를 지정하는 부울 옵션False

이행

Dhall 패키지 빌더가 작동하는 방식은 다음과 같습니다.

  • 먼저 -f-with-http플래그로 Haskell Dhall 패키지를 빌드하십시오.

    이 플래그는 HTTP 원격 가져 오기에 대한 지원을 컴파일합니다. 이렇게하면 사용자가 원격 가져 오기에 대한 종속성을 제공하는 것을 잊은 경우 다음과 같은 오류 메시지가 표시됩니다. Import resolution is disabled

    이후의 모든 단계에서이 실행 파일을 사용합니다.

  • 현재 작업 디렉토리 내에 캐시 디렉토리를 만듭니다. .cache/dhall

    ... 캐시 디렉토리를 각 종속성의 ./cache/디렉토리에 저장된 바이너리 파일로 채 웁니다.

  • 우리가 만든 캐시 디렉토리를 사용하도록 인터프리터를 구성하십시오.

    ... 현재 작업 디렉토리에서 방금 만든 디렉토리 XDG_CACHE_HOME를 가리 키도록 설정 하여.cache

  • 패키지의 Dhall 소스 코드 해석 및 α 정규화

    ... dhall --alpha명령 사용. 에 결과를 저장 한 $out/source.dhall곳을 $out최종 빌드 제품을 저장할 디렉토리입니다

  • 식의 해시 얻기

    ... dhall hash명령 사용. 다음 두 단계를 위해이 해시가 필요합니다.

  • 해당 바이너리 캐시 파일을 만듭니다.

    ... dhall encode명령을 사용하여 파일을$out/cache/dhall/1220${HASH}

  • ./binary.dhall파일 생성

    ... $out/binary.dhall포함에 텍스트 파일을 작성하여missing sha256:${HASH}

  • 선택 사항 : ./source.dhall파일 삭제

    ... 사용자가 파일 보관을 요청하지 않은 경우. 기본적으로이 파일을 생략하면 동일한 표현식을 이진 파일과 소스 코드로 두 번 저장하지 않으므로 패키지 저장소 내의 공간을 절약 할 수 있습니다.

포장 규칙

이 기능이 있으면 "대규모"작업을 단순화하는 데 도움이되는 몇 가지 규칙이 있습니다.

  • 기본적으로 패키지는 프로젝트의 ./package.dhall파일을 빌드해야 합니다.

  • 패키지 버전을 쉽게 덮어 쓰기

  • 패키지 내에 빌드 된 파일을 쉽게 재정의 할 수 있도록합니다.

    즉, 사용자 https://prelude.dhall-lang.org/List/map가 최상위 ./package.dhall파일 대신에 개별 파일을 가져 오는 것을 선호하는 경우 Prelude.override { file = "./List/map"; }해당 개별 파일을 빌드하고 캐시하는 패키지를 얻는 것과 같은 종속성을 지정할 수있는 방법이 있어야 합니다.

결론

도움이 되었기를 바랍니다. 이 작업을 수행하는 방법에 대해 더 많은 질문이있는 경우 여기에서 질문하거나 Discourse 포럼, 특히이 관용구가 처음 시작된 스레드에서 더 많은 토론을 할 수 있습니다.

이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.

침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제

에서 수정
0

몇 마디 만하겠습니다

0리뷰
로그인참여 후 검토

관련 기사

Related 관련 기사

뜨겁다태그

보관