Dış bağımlılıklara genel bakış

Sorun bildir Kaynağı göster

Bazel, derlemenizde kullanılan ve çalışma alanınıza ait olmayan harici bağımlılıkları, kaynak dosyaları (hem metin hem de ikili) destekler. Örneğin, GitHub deposunda barındırılan bir kural kümesi, Maven yapısı veya mevcut çalışma alanınızın dışındaki yerel makinenizde bulunan bir dizin olabilir.

Bazel 6.0'dan itibaren Bazel ile dış bağımlılıkları yönetmenin iki yolu vardır: geleneksel, depo odaklı WORKSPACE sistemi ve yeni modül odaklı MODULE.bazel sistemi (Bzlmod olarak adlandırılmış ve --enable_bzlmod işaretiyle etkinleştirilmiştir). İki sistem birlikte kullanılabilir ancak Bzlmods, gelecekteki Bazlmods'ta taşıma rehberinin yerini alacak.WORKSPACE

Bu belgede, sırasıyla iki sistemi biraz daha ayrıntılı bir şekilde ele almadan önce Bazel'de dış bağımlılık yönetimiyle ilgili kavramlar açıklanmaktadır.

Kavramlar

Depo

Kökünde bir sınır işaretçi dosyası bulunan ve Bazel derlemesinde kullanılabilecek kaynak dosyaları içeren bir dizin ağacı. Genellikle sadece depo olarak kısaltılır.

Depo sınır işaretçisi dosyası MODULE.bazel (bu deponun bir Bazel modülünü temsil ettiğinin sinyalini verir), REPO.bazel (aşağıya bakın) ya da eski bağlamlarda WORKSPACE veya WORKSPACE.bazel olabilir. Herhangi bir depo sınır işaretçisi dosyası, bir deponun sınırını belirtir. Bir dizinde, bu tür birden fazla dosya bir arada bulunabilir.

Ana kod deposu

Geçerli Bazel komutunun çalıştırıldığı depo.

Ana deponun kökü, workspace kökü olarak da bilinir.

Workspace

Tüm Bazel komutları tarafından paylaşılan ortam aynı ana depoda çalışır. Ana depoyu ve tanımlanan tüm harici depolar kümesini kapsar.

Geçmişte "depo" ve "çalışma alanı" kavramlarının birleştirildiğini unutmayın. "Çalışma alanı" terimi çoğu zaman ana depoyu belirtmek için kullanılır ve bazen "depo" ile eş anlamlı olarak da kullanılır.

Standart kod deposu adı

Kod deposunun adreslenebileceği standart ad. Çalışma alanı bağlamında, her deponun tek bir standart adı vardır. Standart adı canonical_name olan bir depo içindeki bir hedef, @@canonical_name//pac/kage:target etiketiyle ele alınabilir (çift @'ye dikkat edin).

Ana depoda standart ad olarak her zaman boş dize bulunur.

Belirgin kod deposu adı

Bir kod deposunun, başka bir kod deposu bağlamında ele alınabileceği ad. Bu, kod deposunun "takma adı" olarak düşünülebilir: Deponun "takma adı" olarak düşünülebilir: michael kod deposu bağlamında mike görünen adı alice iken kod deposu bağlamında "mickey" olabilir.bob Bu durumda, michael içindeki bir hedefe alice bağlamında @mike//pac/kage:target etiketi ile hitap edilebilir (tek @ öğesine dikkat edin).

Buna karşılık, bu durum depo eşlemesi olarak anlaşılabilir: Her depo, "görünen kod deposu adı" ile "standart kod deposu adı" arasında bir eşleme sağlar.

Kod deposu kuralı

Bazel'a bir depoyu nasıl hayata geçireceğini söyleyen depo tanımları şeması. Örneğin, "belirli bir URL'den zip arşivi indir ve çıkar", "belirli bir Maven yapısını getir ve java_import hedefi olarak kullanılabilir hale getir" ya da "yerel bir dizinin sembolüyle bağlantılandır" olabilir. Her kod, uygun sayıda bağımsız değişkene sahip bir depo kuralının çağrılmasıyla tanımlanır.

Kendi depo kurallarınızı yazma hakkında daha fazla bilgi için Depo kuralları bölümüne bakın.

Şu ana kadarki en yaygın depo kuralları şunlardır: URL'den bir arşiv indirip çıkaran http_archive ve zaten bir Bazel deposu olan yerel bir dizini sembolize eden local_repository.

Kod deposu alma

Bir depoyu, ilişkili depo kuralını çalıştırarak yerel diskte kullanılabilir hale getirme işlemi. Çalışma alanında tanımlanan depolar, getirilmeden önce yerel disk üzerinde kullanılamaz.

Normalde Bazel, yalnızca kod deposundan bir şey gerektiğinde ve henüz getirilmediğinde depo getirir. Depo daha önce getirildiyse Bazel yalnızca tanımı değişirse bunu tekrar getirir.

fetch komutu; bir depo, hedef veya derleme gerçekleştirmek için gereken tüm depolar için önceden getirme işlemi başlatmak amacıyla kullanılabilir. Bu özellik, --nofetch seçeneği ile çevrimdışı derlemeleri etkinleştirir.

--fetch seçeneği, ağ erişimini yönetmek için kullanılır. Varsayılan değeri true (doğru) şeklindedir. Ancak false (--nofetch) değerine ayarlanırsa komut, bağımlılığın önbelleğe alınmış herhangi bir sürümünü kullanır. Böyle bir sürüm yoksa komut başarısız olur.

Getirme denetimi hakkında daha fazla bilgi için getirme seçeneklerine bakın.

Dizin düzeni

Kod deposu, getirildikten sonra çıktı tabanındaki external alt dizininde, standart adının altında bulunabilir.

canonical_name kod deposunun içeriğini görmek için aşağıdaki komutu çalıştırabilirsiniz:

ls $(bazel info output_base)/external/ canonical_name 

REPO.bazel dosyası

REPO.bazel dosyası, depo oluşturan dizin ağacının en üst sınırını işaretlemek için kullanılır. Depo sınır dosyası görevi görecek herhangi bir şey içermesine gerek yoktur ancak kod deposu içindeki tüm derleme hedefleri için bazı ortak özellikler belirtmek amacıyla da kullanılabilir.

REPO.bazel dosyasının söz dizimi BUILD dosyalarına benzerdir. Tek fark, load ifadelerinin desteklenmediği ve yalnızca tek bir işlev (repo()) kullanılabilir. repo(), BUILD dosyalarındaki package() işleviyle aynı bağımsız değişkenleri alır. package() ise paket içindeki tüm derleme hedefleri için ortak özellikleri belirtirken repo(), kod deposu içindeki tüm derleme hedefleri için bunu benzer şekilde yapar.

Örneğin, aşağıdaki REPO.bazel dosyasını kullanarak deponuzdaki tüm hedefler için ortak bir lisans belirtebilirsiniz:

repo(
    default_package_metadata = ["//:my_license"],
)

Bzlmod ile dış bağımlılıkları yönetin

Yeni dış bağımlılık alt sistemi olan Bzlmod, depo tanımlarıyla doğrudan çalışmaz. Bunun yerine modüllerden bir bağımlılık grafiği oluşturur, grafiğin üstünde uzantılar çalıştırır ve depoları buna göre tanımlar.

Bazel modülü, birden çok sürümü olabilen bir Bazel projesidir. Bu sürümlerin her biri bağlı olduğu modüller hakkında meta veriler yayınlar. Bir modülün deposunda, WORKSPACE dosyasının yanında MODULE.bazel dosyası olmalıdır. Bu dosya, diğer bilgilerin yanı sıra adını, sürümünü, bağımlılık listesini de belirten modülün manifest dosyasıdır. Aşağıda temel bir örnek verilmiştir:

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

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

Modül yalnızca Bzlmod'un bir Bazel kayıt defterinde (varsayılan olarak Bazel CentralRegistry) aradığı doğrudan bağımlılıklarını listelemelidir. Kayıt defteri, bağımlıların MODULE.bazel dosyalarını sağlar. Böylece Bazel, sürüm çözünürlüğünü gerçekleştirmeden önce geçişli bağımlılık grafiğinin tamamını keşfedebilir.

Her modül için bir sürümün seçildiği sürüm çözünürlüğünden sonra Bazel, her modül için bir depo tanımlamayı (çoğu durumda http_archive kullanarak) öğrenmek üzere kayıt defterine tekrar danışır.

Modüller, etiket adı verilen özelleştirilmiş veri parçalarını da belirtebilir. Bunlar, ek depolar tanımlamak için modül çözünürlüğünden sonra modül uzantıları tarafından kullanılır. Bu uzantılar, kod depolarına benzer şekilde, dosya G/Ç ve ağ istekleri gönderme gibi işlemler gerçekleştirmelerine olanak tanır. Diğer işlerinin yanı sıra, Bazel'ın diğer paket yönetim sistemleriyle etkileşim kurmasına olanak tanırken Bazel modülleriyle oluşturulan bağımlılık grafiğine de uymuş olurlar.

WORKSPACE ile kod depolarını tanımlayın

Geçmişte WORKSPACE (veya WORKSPACE.bazel) dosyasında depo tanımlayarak harici bağımlılıkları yönetebilirsiniz. Bu dosya, BUILD dosyalarına benzer bir söz dizimine sahiptir ve derleme kuralları yerine depo kuralları kullanır.

Aşağıdaki snippet, WORKSPACE dosyasında http_archive deposu kuralını kullanmaya yönelik bir örnektir:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "foo",
    urls = ["https://example.com/foo.zip"],
    sha256 = "c9526390a7cd420fdcec2988b4f3626fe9c5b51e2959f685e8f4d170d1a9bd96",
)

Snippet, standart adı foo olan bir depo tanımlar. WORKSPACE sisteminde varsayılan olarak bir deponun standart adı, diğer tüm depolar için de görünen addır.

WORKSPACE dosyalarında bulunan işlevlerin tam listesini inceleyin.

WORKSPACE sisteminin eksiklikleri

WORKSPACE sisteminin kullanıma sunulmasından bu yana geçen yıllarda kullanıcılar aşağıdakiler de dahil olmak üzere birçok sorun bildirdi:

  • Bazel, herhangi bir bağımlılığın WORKSPACE dosyalarını değerlendirmez. Bu nedenle, doğrudan bağımlılıkların yanı sıra tüm geçişli bağımlılıklar ana deponun WORKSPACE dosyasında tanımlanmalıdır.
  • Bu sorunu gidermek için projeler "deps.bzl" kalıbını benimsemiştir. Bu modelde birden çok depo tanımlayan bir makro tanımlanır ve kullanıcılardan bu makroyu WORKSPACE dosyalarında çağırmaları istenir.
    • Bunun kendine ait sorunları vardır: Makrolar diğer .bzl dosyalarını load yapamaz. Dolayısıyla bu projelerin, bu "deps" makrosunda geçişli bağımlılıklarını tanımlaması veya kullanıcının birden çok katmanlı "deps" makrosu çağırmasını sağlayarak bu sorunu çözmesi gerekir.
    • Bazel, WORKSPACE dosyasını sırayla değerlendirir. Ayrıca bağımlılıklar, herhangi bir sürüm bilgisi olmadan URL'lerle http_archive kullanılarak belirtilir. Bu, elmas bağımlılıklarında sürüm çözümlemeyi yapmanın güvenilir bir yolu olmadığı anlamına gelir (A, B ve C özelliklerine bağlıdır; B ve C ikisi de D'in farklı sürümlerine bağlıdır).

WORKSPACE'in eksiklikleri nedeniyle Bzlmod, gelecekteki Bazel sürümlerinde eski WORKSPACE sisteminin yerini alacak. Lütfen Bzlmod'a nasıl geçiş yapacağınızla ilgili olarak Bzlmod geçiş kılavuzunu okuyun.