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

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

Bu belgede, bazı kavramlar daha ayrıntılı olarak incelenmeden önce sisteme genel bir bakış sunulmaktadır.

Sisteme genel bakış

Bazel'in harici bağımlılık sistemi, her biri sürüm oluşturulmuş bir Bazel projesi olan Bazel modüllerine ve kaynak dosyaları içeren dizin ağaçları olan depolara (veya repolara) dayanır.

Bazel, kök modülden (üzerinde çalıştığınız proje) başlar. Tüm modüller gibi, bu modülün de dizin kökünde temel meta verilerini ve doğrudan bağımlılıklarını bildiren bir MODULE.bazel dosyası olması gerekir. 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 defterindeki tüm geçişli bağımlılık modüllerini arar. Varsayılan olarak Bazel Central Registry kullanılır. 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 tüm geçişli bağımlılık grafiğini 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 depo nasıl tanımlanacağını (yani her bağımlılık modülünün kaynaklarının nasıl getirileceğini) öğrenmek için kayıt defterine tekrar danışır. Çoğu zaman bunlar, internetten indirilen ve ayıklanan arşivlerdir.

Modüller, etiket adı verilen özelleştirilmiş veri parçaları da belirtebilir. Bu etiketler, ek depoları tanımlamak için modül çözümlendirmesinden sonra modül uzantıları tarafından kullanılır. Bu uzantılar, dosya G/Ç ve ağ isteği gönderme gibi işlemler gerçekleştirebilir. Diğer işlevlerinin yanı sıra, Bazel modüllerinden oluşturulan bağımlılık grafiğine de saygı duyarak Bazel'in diğer paket yönetim sistemleriyle etkileşim kurmasına olanak tanır.

Üç tür depo (ana depo, geçişli bağımlılık modüllerini temsil eden depolar ve modül uzantıları tarafından oluşturulan depolar) birlikte çalışma alanını oluşturur. Harici depolar (ana olmayan depolar), talep üzerine getirilir. Örneğin, BUILD dosyalarındaki etiketler (@repo//pkg:target gibi) tarafından referans verildiğinde.

Avantajları

Bazel'in harici bağımlılık sistemi çok çeşitli avantajlar sunar.

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

  • Belirleyici Sürüm Çözümü: Bazel, belirleyici MVS sürüm çözümleme algoritmasını kullanır. Bu sayede çakışmalar en aza indirilir ve elmas bağımlılığı sorunları giderilir.
  • Basitleştirilmiş Bağımlılık Yönetimi: MODULE.bazel yalnızca doğrudan bağımlılıkları bildirirken geçişli bağımlılıklar otomatik olarak çözülür. Böylece projenin bağımlılıkları hakkında daha net bir genel bakış sunulur.
  • Katı bağımlılık görünürlüğü: Yalnızca doğrudan bağımlılıklar görünür. Bu sayede doğruluk ve tahmin edilebilirlik sağlanır.

Ekosistem Entegrasyonu

  • Bazel Merkezi Kayıt Defteri: Bazel modülleri olarak ortak bağımlılıkları keşfetmek ve yönetmek için merkezi bir depo.
  • Bazel dışı projelerin benimsenmesi: Bazel dışı bir proje (genellikle bir C++ kitaplığı) Bazel'e uyarlanıp BCR'de kullanıma sunulduğunda tüm topluluk için entegrasyonu kolaylaştırır, yinelenen çabaları ve özel BUILD dosyalarının çakışmalarını ortadan kaldırır.
  • Dile Özgü Paket Yöneticileriyle Birleştirilmiş Entegrasyon: Kural kümeleri, aşağıdakiler dahil olmak üzere Bazel dışı bağımlılıklar için harici paket yöneticileriyle entegrasyonu kolaylaştırır:

İleri Seviye Özellikler

  • Modül Uzantıları: use_repo_rule ve modül uzantısı özellikleri, Bazel dışı bağımlılıkları kullanmak için özel depo kurallarının ve çözümleme mantığının esnek bir şekilde kullanılmasını sağlar.
  • bazel mod Command: Alt komut, harici bağımlılıkları incelemek için güçlü yöntemler sunar. Harici bağımlılığın nasıl tanımlandığını ve nereden geldiğini tam olarak biliyorsunuz.
  • Tedarikçi Modu: Çevrimdışı derlemeleri kolaylaştırmak için ihtiyacınız olan harici bağımlılıkları önceden getirin.
  • Lockfile: Lockfile, derleme tekrarlanabilirliğini artırır ve bağımlılık çözümünü hızlandırır.
  • (Yakında) BCR Provenance Attestations: Bağımlılıkların doğrulanmış kaynağını sağlayarak tedarik zinciri güvenliğini güçlendirin.

Kavramlar

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

Modül

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

Yerel bir Bazel çalışma alanında modül, bir depo ile temsil edilir.

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

Kod deposu

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

Depo sınır işaretleyici dosyası MODULE.bazel (bu deponun bir Bazel modülünü temsil ettiğini gösterir), REPO.bazel (aşağıya bakın) veya eski bağlamlarda WORKSPACE ya da WORKSPACE.bazel olabilir. Herhangi bir depo sınırı işaretleyici dosyası, deponun sınırını gösterir. Bir dizinde birden fazla depo sınırı işaretleyici dosyası bulunabilir.

Ana depo

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

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

Workspace

Tüm Bazel komutlarının paylaştığı ortam, aynı ana depoda çalışır. Ana depoyu ve tanımlanmış 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 ifade etmek için, bazen de "depo" ile eş anlamlı olarak kullanılmıştır.

Standart depo adı

Bir deponun her zaman adreslenebilir olduğu ad. Bir çalışma alanı bağlamında her depoda tek bir kanonik ad bulunur. Depo içindeki, standart adı canonical_name olan bir hedef, @@canonical_name//package:target etiketiyle (çift @ karakterine dikkat edin) ele alınabilir.

Ana deponun kanonik adı her zaman boş dizedir.

Görünen depo adı

Bir deponun belirli bir başka depo bağlamında adreslenebilir olduğu ad. Bu, bir depodaki "takma ad" olarak düşünülebilir: Standart adı michael olan bir 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, alice bağlamında @mike//package:target etiketiyle ele alınabilir (tek @ olduğuna dikkat edin).

Bunun tersi ise depo eşlemesi olarak anlaşılabilir: Her depo, "görünen depo adı" ile "kanonik depo adı" arasında bir eşleme tutar.

Depo kuralı

Depo tanımları için bir şema. Bu şema, Bazel'e bir depoyu nasıl oluşturacağını söyler. Örneğin, "belirli bir URL'den zip arşivi indir ve ayıkla", "belirli bir Maven yapısını getir ve java_import hedefi olarak kullanılabilir hale getir" veya yalnızca "yerel bir dizine sembolik bağlantı oluştur" 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.

En yaygın depo kuralları, bir URL'den arşiv indirip çıkaran http_archive ve yerel bir dizini (zaten bir Bazel deposu olan) sembolik olarak bağlayan local_repository'dır.

Depo getirme

İlişkili depo kuralı çalıştırılarak bir deponun yerel diskte kullanılabilir hale getirilmesi işlemi. Bir çalışma alanında tanımlanan depolar, getirilmeden önce yerel diskte kullanılamaz.

Normalde Bazel, yalnızca depodan bir şey gerektiğinde ve depo henüz getirilmediyse depoyu getirir. Depo daha önce getirilmişse Bazel, yalnızca tanımı değiştiğinde depoyu yeniden getirir.

fetch komutu, bir kod deposu, hedef veya gerekli tüm kod depoları için önceden getirme işlemi başlatmak üzere kullanılabilir. Bu özellik, --nofetch seçeneği kullanılarak çevrimdışı derlemelerin oluşturulmasını sağlar.

--fetch seçeneği, ağ erişimini yönetmek için kullanılır. Varsayılan değeri true'dur. Ancak false olarak ayarlandığında (--nofetch) komut, bağımlılığın önbelleğe alınmış herhangi bir sürümünü kullanır ve böyle bir 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 başlıklı makaleye bakın.

Dizin düzeni

Getirildikten sonra depo, output base'deki external alt dizininde, kurallı adıyla bulunabilir.

Deponun içeriğini kanonik ad canonical_name ile 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 üstteki sınırını işaretlemek için kullanılır. Depo sınır dosyası olarak kullanılmak için herhangi bir şey içermesi gerekmez. Ancak, depodaki tüm derleme hedefleri için bazı ortak özellikleri belirtmek üzere de kullanılabilir.

REPO.bazel dosyasının söz dizimi, BUILD dosyalarına benzer. Ancak load ifadeleri desteklenmez. 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 belirtirken repo() benzer şekilde depo içindeki tüm derleme hedefleri için ortak özellikleri belirtir.

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

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

Eski WORKSPACE sistemi

Daha eski Bazel sürümlerinde (9.0'dan önce) harici bağımlılıklar, WORKSPACE (veya WORKSPACE.bazel) dosyasında depolar tanımlanarak tanıtılıyordu. Bu dosya, derleme kuralları yerine depo kurallarını kullanarak BUILD dosyalarına benzer bir söz dizimine sahiptir.

Aşağıdaki snippet, http_archive repo kuralını WORKSPACE dosyasında kullanma örneğidir:

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ımlıyor. WORKSPACE sisteminde, bir deponun kurallı adı varsayılan olarak diğer tüm depolar için de görünen adıdır.

WORKSPACE dosyalarında kullanılabilen işlevlerin tam listesini inceleyin.

WORKSPACE sisteminin eksiklikleri

WORKSPACE sistemi kullanıma sunulduktan 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, doğrudan bağımlılıkların yanı sıra tüm geçişli bağımlılıklar da ana deponun WORKSPACE dosyasında tanımlanmalıdır.
  • Bu sorunu çözmek için projelerde "deps.bzl" kalıbı benimsenmiştir. 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.
    • Bu durumun kendi sorunları vardır: Makrolar diğer load dosyaları .bzl yapamaz. Bu nedenle, bu projelerin geçişli bağımlılıklarını bu "deps" makrosunda tanımlaması veya kullanıcının çok katmanlı "deps" makrolarını çağırmasını sağlayarak bu sorunu çözmesi gerekir.
    • Bazel, WORKSPACE dosyasını sırayla değerlendirir. Ayrıca, bağımlılıklar URL'lerle birlikte http_archive kullanılarak belirtilir ve sürüm bilgisi içermez. Bu, elmas bağımlılıkları (A, B ve C'ye bağlıdır; B ve C ise D'ün farklı sürümlerine bağlıdır) söz konusu olduğunda sürüm çözümlemesi yapmanın güvenilir bir yolu olmadığı anlamına gelir.

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