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

Sorun bildir Kaynağı görüntüle 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.

Bazel 6.0 itibarıyla, Bazel ile harici bağımlılıkları yönetmenin iki yolu vardır: geleneksel, depo odaklı WORKSPACE sistemi ve daha yeni, modül odaklı MODULE.bazel sistemi (kod adı Bzlmod olup --enable_bzlmod işaretiyle etkinleştirilir). İki sistem birlikte kullanılabilir ancak Bzlmod, gelecekteki Bazel sürümlerinde WORKSPACE sisteminin yerini alacaktır. Nasıl geçiş yapacağınızla ilgili bilgileri Bzlmod geçiş kılavuzunda bulabilirsiniz.

Bu belgede, iki sistem hakkında biraz daha ayrıntılı bilgi verilmeden önce Bazel'deki harici bağımlılık yönetimiyle ilgili kavramlar açıklanmaktadır.

Kavramlar

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.

Çalışma alanı

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 adreslenebilir olduğu kurallı 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//pac/kage: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 adreslenebildiği ad. Bu, bir depodaki "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, alice bağlamında @mike//pac/kage: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. Ç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ışı 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 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() Paketin içindeki tüm derleme hedefleri için ortak özellikleri belirtirken repo() aynı ş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"],
)

Bzlmod ile harici bağımlılıkları yönetme

Yeni harici 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 üzerinde uzantılar çalıştırır ve depoları buna göre tanımlar.

Bazel modülü, birden fazla sürümü olabilen bir Bazel projesidir. Bu sürümlerin her biri, bağlı olduğu diğer modüllerle ilgili meta veriler yayınlar. Bir modülün, depo kök dizininde WORKSPACE dosyasının yanında MODULE.bazel dosyası olmalıdır. Bu dosya, modülün adını, sürümünü, bağımlılık listesini ve diğer bilgileri bildiren 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")

Bir modül yalnızca doğrudan bağımlılıklarını listelemelidir. Bzlmod, bu bağımlılıkları Bazel kayıt defterinde (varsayılan olarak Bazel Central Registry) arar. Kayıt defteri, MODULE.bazel dosyalarını sağlar. Bu sayede Bazel, sürüm çözümlemesi yapmadan ö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 tanımlamayı öğ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ı 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, depo kurallarına benzer özelliklere sahiptir. Bu sayede dosya G/Ç'si ve ağ isteği gönderme gibi işlemler gerçekleştirebilirler. Diğer işlevlerinin yanı sıra, Bazel modüllerinden oluşturulan bağımlılık grafiğine de uymakla birlikte Bazel'in diğer paket yönetim sistemleriyle etkileşim kurmasına olanak tanır.

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ını kullanır.

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 sunulduğundan beri kullanıcılar aşağıdakiler de dahil olmak üzere birçok sorun yaşadıklarını 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 Bzlmod, gelecekteki Bazel sürümlerinde eski WORKSPACE sisteminin yerini alacak. Bzlmod'a geçiş hakkında bilgi edinmek için lütfen Bzlmod'a geçiş kılavuzunu okuyun.