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

Bazel, derlemenizde kullanılan ve çalışma alanınızdan olmayan kaynak dosyaları (hem metin hem de ikili) olan harici bağımlılıkları destekler. Örneğin, GitHub deposunda barındırılan bir kural grubu, 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 harici bağımlılıkları yönetmenin iki yolu vardır: Geleneksel, depoya odaklanan WORKSPACE sistemi ve daha yeni modüle odaklanan MODULE.bazel sistemi (Bzlmod kod adındadır ve --enable_bzlmod işaretiyle etkinleştirilir). Bu iki sistem birlikte kullanılabilir ancak Bzlmod, gelecekteki Bazel sürümlerinde WORKSPACE sisteminin yerini alacak. Taşıma işlemiyle ilgili Bzlmod taşıma kılavuzunu inceleyin.

Bu belgede, Bazel'de harici bağımlılık yönetimiyle ilgili kavramlar açıklandıktan sonra iki sistem hakkında biraz daha ayrıntılı bilgi verilmektedir.

Kavramlar

Kod deposu

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

Depo sınır işaretçisi dosyası MODULE.bazel (bu reponun bir Bazel modülü temsil ettiğini belirtir), REPO.bazel (aşağıya bakın) veya eski bağlamlarda WORKSPACE ya da 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 bulunabilir.

Ana depo

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

Çalışma alanı

Tüm Bazel komutları tarafından paylaşılan ortam, aynı ana depoda çalışır.

Geçmişte "depo" ve "çalışma alanı" kavramlarının karıştırıldığını unutmayın. "Çalışma alanı" terimi, genellikle ana depoyu ifade etmek için kullanılmış, hatta bazen "depo"nun eş anlamlısı olarak bile kullanılmıştır.

Standart depo adı

Bir deponun adreslenebilir olduğu kurallı ad. Bir çalışma alanı bağlamında her deponun tek bir standart adı vardır. Bir depoda, standart adı canonical_name olan bir hedef, @@canonical_name//pac/kage:target etiketiyle (çift @'ye dikkat edin) adreslenebilir.

Ana deponun kanon adı her zaman boş dizedir.

Görünen depo adı

Bir deponun, belirli bir depo bağlamında erişilebilir olduğu ad. Bu, bir deponun "takma adı" olarak düşünülebilir: michael kanonik adına sahip depo, alice deposu bağlamında mike görünen adına sahip olabilir ancak bob deposu bağlamında mickey görünen adına sahip olabilir. Bu durumda, michael içindeki bir hedef, @mike//pac/kage:target etiketi tarafından alice bağlamında ele alınabilir (@ öğesine dikkat edin).

Tersine, bu bir depo eşlemesi olarak da anlaşılabilir: Her depo, "görünür depo adı" ile "kanonik depo adı" arasında bir eşleme sağlar.

Depo kuralı

Bazel'e bir deposu nasıl somutlaştıracağını söyleyen depo tanımları için bir şema. Örneğin, "belirli bir URL'den zip arşivi indirip ayıklayın" veya "belirli bir Maven yapısını getirip java_import hedefi olarak kullanılabilir hale getirin" ya da "yerel bir dizine simge bağlantısı oluşturun" olabilir. Her depo, uygun sayıda bağımsız değişkenle bir depo kuralı çağrılarak tanımlanır.

Kendi depo kurallarınızı yazma hakkında daha fazla bilgi için Depo kuralları başlıklı makaleyi inceleyin.

Depo kurallarının en yaygını, bir URL'den arşiv indirip ayıklayan http_archive ve zaten Bazel deposu olan yerel bir dizine simge bağlantısı oluşturan local_repository kurallarıdır.

Depo getirme

İlişkili repo kuralını çalıştırarak bir repoyu yerel diskte kullanılabilir hale getirme işlemi. Bir çalışma alanında tanımlanan depolar, getirilmeden önce yerel diskte kullanılamaz.

Normalde, Bazel bir depoyu yalnızca depodan bir şey gerektiğinde getirir ve depo henüz getirilmemiştir. Depo daha önce getirildiyse Bazel, yalnızca tanımı değiştiyse depoyu yeniden getirir.

fetch komutu, herhangi bir derleme gerçekleştirmek için depo, hedef veya gerekli tüm depolar için önceden getirme işlemini başlatmak amacıyla kullanılabilir. Bu özellik, --nofetch seçeneğini kullanarak ç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) değerini alır. Ancak yanlış (--nofetch) olarak ayarlandığında komut, bağımlığın önbelleğe alınmış bir sürümünü kullanır. Önbelleğe alınmış sürüm yoksa komut başarısız olur.

Getirme işlemini kontrol etme hakkında daha fazla bilgi için getirme seçenekleri bölümüne bakın.

Dizin düzeni

Depo, getirildikten sonra çıktı tabanında external alt dizinindeki kurallı adının altında bulunabilir.

Standart ad olan canonical_name ile deponun 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ı, bir depoyu 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ı olarak hizmet etmek için herhangi bir şey içermesi gerekmez. Ancak, depodaki tüm derleme hedefleri için bazı ortak özellikleri belirtmek amacıyla da kullanılabilir.

REPO.bazel dosyalarının söz dizimi, BUILD dosyalarına benzer. Bununla birlikte, load ifadeleri desteklenmez ve yalnızca repo() işlevi 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 belirtir. repo() ise benzer şekilde depo içindeki tüm derleme hedefleri için bunu 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 harici bağımlılıkları yönetme

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

Bazel modülü, birden fazla sürümü olabilecek bir Bazel projesidir. Her sürüm, bağımlı olduğu diğer modüller hakkında meta veriler yayınlar. Bir modülün, depo kökünde WORKSPACE dosyasının yanında bir MODULE.bazel dosyası olmalıdır. Bu dosya, modülün manifest dosyasıdır. Modülün adını, sürümünü, bağımlılık listesini ve diğer bilgilerini belirtir. 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")

Bir modül yalnızca Bzlmod'un bir Bazel kayıt otoritesinde (varsayılan olarak Bazel Merkez Kayıt otoritesi) aradığı doğrudan bağımlılıklarını listelemelidir. Kayıt defteri, bağımlılıkların MODULE.bazel dosyalarını sağlar. Bu sayede Bazel, sürüm çözümlemesi yapmadan ö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ümlemesinden sonra Bazel, her modül için bir deponun nasıl tanımlanacağını öğrenmek üzere kayıt defterine tekrar danışır (çoğu durumda http_archive kullanılarak).

Modüller, etiket adı verilen özelleştirilmiş veri parçalarını da belirtebilir. Bu veriler, ek depoları tanımlamak için modül çözüldükten sonra modül uzantıları tarafından kullanılır. Bu uzantılar, depo kurallarına benzer özellikler sunarak dosya G/Ç ve ağ istekleri gönderme gibi işlemleri gerçekleştirmelerini sağlar. Ayrıca, Bazel'in diğer paket yönetim sistemleriyle etkileşim kurmasına olanak tanırken Bazel modüllerinden oluşturulan bağımlılık grafiğine de saygı gösterirler.

WORKSPACE ile depoları tanımlama

Geçmişte, WORKSPACE (veya WORKSPACE.bazel) dosyasında depoları tanımlayarak harici bağımlılıkları yönetebiliyordunuz. 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 kod 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 depoyu tanımlıyor. WORKSPACE sisteminde, varsayılan olarak bir deponun kurallı adı, diğer tüm depolar için görünen adıdır.

WORKSPACE dosyalarında kullanılabilen işlevlerin tam listesine göz atın.

WORKSPACE sistemindeki eksikler

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 yaşadığını bildirdi:

  • Bazel, bağımlılıkların WORKSPACE dosyalarını değerlendirmez. Bu nedenle, tüm geçişli bağımlılıkların doğrudan bağımlılıklara ek olarak ana deponun WORKSPACE dosyasında tanımlanması gerekir.
  • Bu sorunun üstesinden gelmek için projeler "deps.bzl" kalıbını benimsedi. Bu kalıpta, birden fazla depoyu tanımlayan bir makro tanımlanır ve kullanıcılardan bu makroyu WORKSPACE dosyalarında çağırmaları istenir.
    • Bunun da kendine özgü sorunları vardır: Makrolar diğer .bzl dosyalarını load edemez. Bu nedenle, bu projelerin geçişli bağımlılıklarını bu "deps" makrosunda tanımlaması veya kullanıcının birden fazla katmanlı "deps" makrosu çağırmasını sağlayarak bu sorunu gidermesi gerekir.
    • Bazel, WORKSPACE dosyasını sırayla değerlendirir. Ayrıca, bağımlılıklar herhangi bir sürüm bilgisi olmadan URL'lerle birlikte http_archive kullanılarak belirtilir. Bu, elmas bağımlılıklarında (A, B ve C'ye bağlıdır; B ve C, D'ın farklı sürümlerine bağlıdır) sürüm çözümlemesi yapmanın güvenilir bir yolu olmadığı anlamına gelir.

WORKSPACE'in eksiklikleri nedeniyle Bzlmod, gelecekteki Bazel sürümlerinde eski WORKSPACE sisteminin yerini alacak. Bzlmod'a geçiş hakkında lütfen Bzlmod taşıma kılavuzunu okuyun.