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

Nightly · 9.0 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

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 yerel makinenizde 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, temel meta verilerini ve doğrudan bağımlılıklarını bildiren bir MODULE.bazel dosyasına sahip 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")

Bazel, bu noktadan itibaren tüm geçişli bağımlılık modüllerini bir Bazel kayıt defterinde (varsayılan olarak Bazel Central Registry) 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 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ı öğrenmek üzere kayıt defterine tekrar danışır. Bu, her bağımlılık modülünün kaynaklarının nasıl getirileceği anlamına gelir. Ç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şlemleri 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) isteğe bağlı olarak getirilir. Örneğin, BUILD dosyalarında etiketlerle (@repo//pkg:target gibi) 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ına dair 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ılır, yinelenen çabalar ve özel BUILD dosyalarının çakışmaları ortadan kaldırılı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 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ş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

Aynı ana depoda çalışan tüm Bazel komutlarının paylaştığı ortam. 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. Standart adı canonical_name olan bir depodaki hedef, @@canonical_name//package:target etiketiyle (çift @ karakterine dikkat edin) ele alınabilir.

Ana deponun her zaman boş dize olarak kanonik adı vardır.

Görünen depo adı

Bir deponun belirli bir başka depo bağlamında adreslenebilir olduğu ad. Bu, bir deponun "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 "standart depo adı" arasında bir eşleme tutar.

Depo kuralı

Bazel'e bir depoyu nasıl oluşturacağını bildiren, depo tanımlarına yönelik bir şema. Örneğin, "belirli bir URL'den ZIP arşivi indirip ayıkla", "belirli bir Maven yapısını getirip java_import hedefi olarak kullanıma sun" 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 zaten bir Bazel deposu olan yerel bir dizini sembolik olarak bağlayan local_repository'tı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ştiyse depoyu yeniden getirir.

fetch komutu, bir kod deposu, hedef veya herhangi bir derleme gerçekleştirmek için gerekli tüm kod depoları için önceden getirme işlemini başlatmak üzere kullanılabilir. Bu özellik, --nofetch seçeneği kullanılarak çevrimdışı derlemeler 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() Paketin içindeki tüm derleme hedefleri için ortak özellikleri belirtirken repo() benzer şekilde depodaki 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 depo 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 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" makrosunu çağırmasını sağlayarak bu sorunu çözmesi gerekir.
    • Bazel, WORKSPACE dosyasını sırayla değerlendirir. Ayrıca, bağımlılıklar http_archive kullanılarak URL'lerle birlikte belirtilir ve sürüm bilgisi içermez. Bu nedenle, 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 yoktur.

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.