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

Sorun bildir Kaynağı görüntüle Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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, bunlar bir GitHub deposunda barındırılan bir kural grubu, bir Maven yapısı veya yerel makinenizde 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 olarak Bzlmod geçiş kılavuzuna bakın.

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

Bazel derlemesinde kullanılacak kaynak dosyaları içeren WORKSPACE veya WORKSPACE.bazel dosyası bulunan bir dizin. Genellikle repo olarak kısaltılır.

Ana depo

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

Çalışma alanı

Tüm Bazel komutlarının paylaştığı ortam, aynı ana depoda çalışır.

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 deponun nasıl oluşturulacağını söyler. Örneğin, "belirli bir URL'den zip arşivi indirip ayıkla", "belirli bir Maven yapıtı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 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.

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

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ı bulunmalı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.bazelbağımlılıklar 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 nasıl geçeceğiniz hakkında bilgi edinmek için lütfen Bzlmod'a geçiş kılavuzunu okuyun.