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.

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, Bazel'deki harici bağımlılık yönetimiyle ilgili kavramlar açıklanmakta ve ardından iki sistem hakkında sırasıyla biraz daha ayrıntılı bilgi verilmektedir.

Kavramlar

Kod deposu

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

Ana depo

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

Workspace

Aynı ana depoda çalışan tüm Bazel komutlarının paylaştığı ortam.

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. Standart adı canonical_name olan bir depodaki hedef, @@canonical_name//pac/kage: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 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 "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.

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, 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 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 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 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 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 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.