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

Sorun bildirme Kaynağı görüntüleme Nightly · 8.2 · 8.1 · 8.0 · 7.6 · 7.5

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 kümesi, Maven yapıları veya mevcut çalışma alanınızın dışındaki yerel makinenizdeki bir dizin olabilir.

Bu dokümanda, bazı kavramları daha ayrıntılı bir şekilde incelemeden önce sisteme genel bir bakış sunulmaktadır.

Sisteme genel bakış

Bazel'in harici bağımlılık sistemi, her biri sürümlü bir Bazel projesi olan Bazel modülleri ve kaynak dosyaları içeren dizin ağaçları olan depolar (veya depolar) temel alınarak çalışır.

Bazel, kök modülden (yani üzerinde çalıştığınız projeden) başlar. Tüm modüller gibi, dizin kökünde temel meta verilerini ve doğrudan bağımlılıkları açıklayan bir MODULE.bazel dosyası olmalıdır. Aşağıda temel bir örnek verilmiştir:

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

bazel_dep(name = "rules_cc", version = "0.1.1")
bazel_dep(name = "platforms", version = "0.0.11")

Ardından Bazel, Bazel kayıt defterinde (varsayılan olarak Bazel Merkezi Kayıt Defteri) tüm geçişli bağımlılık modüllerini arar. Kayıt defteri, bağımlılıkların MODULE.bazel dosyalarını sağlar. Bu sayede Bazel, sürüm çözümlemesi 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ümlemesinden sonra Bazel, her modül için bir deponun nasıl tanımlanacağını (yani her bağımlılık modülünün kaynaklarının nasıl getirileceğini) öğrenmek üzere kayıt defterine tekrar başvurur. Çoğu zaman bunlar internetten indirilen ve ayıklanan arşivlerdir.

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, dosya G/Ç ve ağ isteği gönderme gibi işlemleri gerçekleştirebilir. Bunlar arasında Bazel'in Bazel modüllerinden oluşturulan bağımlılık grafiğine saygı duyarken diğer paket yönetim sistemleriyle etkileşime geçmesine izin verme de vardır.

Ana depo (çalışma yaptığınız kaynak ağaç), geçişli bağımlılık modüllerini temsil eden depolar ve modül uzantıları tarafından oluşturulan depolar olmak üzere üç tür depo, birlikte çalışma alanını oluşturur. Harici depolar (ana depo olmayanlar), BUILD dosyalarında etiketlerle (ör. @repo//pkg:target) atıfta bulunulduğunda isteğe bağlı olarak getirilir.

Avantajları

Bazel'in harici bağımlılık sistemi birçok avantaj sunar.

Otomatik Bağımlılık Çözümü

  • Deterministik Sürüm Çözümü: Bazel, çakışmaları en aza indirip elmas bağımlılık sorunlarını gideren deterministik MVS sürüm çözümü algoritmasını kullanır.
  • Basitleştirilmiş Bağımlılık Yönetimi: MODULE.bazel yalnızca doğrudan bağımlılıkları tanımlar. Geçişli bağımlılıklar ise otomatik olarak çözülür. Böylece projenin bağımlılıklarına daha net bir genel bakış sunulur.
  • Katı Bağımlılık Görünümü: Yalnızca doğrudan bağımlılıklar görünür. Bu sayede doğruluk ve öngörülebilirlik sağlanır.

Ekosistem Entegrasyonu

  • Bazel Merkezi Kaydı: Bazel modülleri olarak yaygın bağımlılıkları keşfetmek ve yönetmek için merkezi bir depo.
  • Bazel dışı projelerin benimsenmesi: Bazel dışı bir proje (genellikle C++ kitaplığı) Bazel'e uyarlandığında ve BCR'de kullanıma sunulduğunda, tüm topluluk için entegrasyonu kolaylaştırılır ve özel BUILD dosyalarının çakışması ve yinelenen çabalar ortadan kaldırılır.
  • Dil Özelinde Paket Yöneticileri ile Birleştirilmiş Entegrasyon: Kural kümeleri, Bazel dışı bağımlılar için harici paket yöneticileriyle entegrasyonu kolaylaştırır. Örneğin:

İleri Seviye Özellikler

  • Modül Uzantıları: use_repo_rule ve modül uzantısı özellikleri, Bazel dışındaki bağımlılıkları tanıtmak için özel depo kurallarının ve çözüm mantığının esnek bir şekilde kullanılmasına olanak tanır.
  • bazel mod Komutu: Alt komut, harici bağımlılıkları incelemenin güçlü yollarını sunar. Harici bağımlılıkların nasıl tanımlandığını ve nereden geldiğini tam olarak bilirsiniz.
  • Tedarikçi Modu: Çevrimdışı derlemeleri kolaylaştırmak için ihtiyaç duyduğunuz harici bağımlılıkları tam olarak önceden getirin.
  • Lockfile: Kilit dosyası, derlemenin yeniden üretilebilirliğini artırır ve bağımlılık çözümlemeyi hızlandırır.
  • (Yakında) BCR Kaynak Belgesi Onayları: Bağımlılıkların doğrulanmış kaynak belgesini sağlayarak tedarik zinciri güvenliğini güçlendirin.

Kavramlar

Bu bölümde, harici bağımlılıklarla ilgili kavramlar hakkında daha fazla ayrıntı verilmektedir.

Modül

Her biri diğer modüllere bağımlı olabilecek birden fazla sürümü olabilecek bir Bazel projesi.

Yerel bir Bazel çalışma alanında modüller depo olarak temsil edilir.

Daha fazla bilgi için Bazel modülleri başlıklı makaleyi inceleyin.

Kod deposu

Kökünde bir 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.

Ana deponun kökü, çalışma alanı kökü olarak da bilinir.

Çalışma alanı

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

Geçmişte "depo" ve "çalışma alanı" kavramlarının birbirine karıştırıldığını unutmayın. "Çalışma alanı" terimi genellikle ana depoyu belirtmek için kullanılmış ve hatta bazen "depo"nun eş anlamlısı olarak 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//package: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, bob deposu bağlamında ise mickey görünen adına sahip olabilir. Bu durumda, michael içindeki bir hedef, alice bağlamında @mike//package:target etiketiyle adreslenebilir (tek @'a dikkat edin).

Tersine, bu bir depo eşleme 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ı getirin ve 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'dir.

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.

Bazel, genellikle yalnızca repodan bir şeye ihtiyaç duyduğunda ve repo henüz getirilmediğinde repoyu getirir. Depo daha önce getirildiyse Bazel, yalnızca tanımı değiştiyse depoyu yeniden getirir.

fetch komutu, bir depo, hedef veya herhangi bir derleme gerçekleştirmek için gerekli tüm depolar için ön getirme işlemi 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.

canonical_name kanonik adına sahip 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 deposu oluşturan dizin ağacının en üst sınırını işaretlemek için kullanılır. Bir 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 dosyasının söz dizimi, load ifadeleri desteklenmediği dışında BUILD dosyalarına benzer. repo() işlevi, BUILD dosyalarındaki package() işleviyle aynı bağımsız değişkenleri alır. package(), paket içindeki tüm derleme hedefleri için ortak özellikleri belirtir. repo() de benzer şekilde, depodaki 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"],
)

Eski WORKSPACE sistemi

Eski Bazel sürümlerinde (9.0'dan önceki sürümler), WORKSPACE (veya WORKSPACE.bazel) dosyasında depoların tanımlanmasıyla harici bağımlılıklar kullanıma sunulmuştur. Bu dosyanın söz dizimi, derleme kuralları yerine depo kuralları kullanan BUILD dosyalarına benzer.

Aşağıdaki snippet, WORKSPACE dosyasında http_archive repo kuralının kullanıldığı 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",
)

Kod snippet'i, kurallı adı foo olan bir deposu tanımlar. 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 sisteminin eksiklikleri

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

  • Bazel, bağımlılıkların WORKSPACE dosyalarını değerlendirmez. Bu nedenle, tüm geçişli bağımlılıklar doğrudan bağımlılıklara ek olarak ana deponun WORKSPACE dosyasında tanımlanmalıdır.
  • 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ümlemenin güvenilir bir yolu olmadığı anlamına gelir.

WORKSPACE'ın eksiklikleri nedeniyle, modüle dayalı yeni sistem ("Bzlmod" kod adıyla) Bazel 6 ile 9 arasında eski WORKSPACE sisteminin yerini kademeli olarak aldı. Bzlmod'a geçiş hakkında Bzlmod taşıma kılavuzunu okuyun.