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 kümesi, Maven yapıları veya mevcut çalışma alanınızın dışındaki yerel makinenizdeki bir dizin olabilir.
Bazel 6.0'dan itibaren, Bazel ile harici bağımlılıkları yönetmenin iki yolu vardır: Geleneksel, depoya odaklanan WORKSPACE
sistemi ve daha yeni modüle odaklanan MODULE.bazel
sistemi (Bzlmod kod adındadır ve --enable_bzlmod
işaretiyle etkinleştirilir). Bu iki sistem birlikte kullanılabilir ancak Bzlmod, gelecekteki Bazel sürümlerinde WORKSPACE
sisteminin yerini alacak. Taşıma işlemiyle ilgili Bzlmod taşıma kılavuzunu inceleyin.
Bu belgede, Bazel'de harici bağımlılık yönetimiyle ilgili kavramlar açıklandıktan sonra iki sistem hakkında biraz daha ayrıntılı bilgi verilmektedir.
Kavramlar
Kod deposu
Bazel derlemesinde kullanılacak kaynak dosyaları içeren bir WORKSPACE
veya WORKSPACE.bazel
dosyası içeren 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ı tarafından paylaşılan 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 belirtmek için kullanılmış ve hatta bazen "depo"nun eş anlamlısı olarak kullanılmıştır.
Standart depo adı
Bir deponun adreslenebilir olduğu kurallı ad. Bir çalışma alanı bağlamında her deponun tek bir standart adı vardır. Bir depoda, standart adı canonical_name
olan bir hedef, @@canonical_name//pac/kage:target
etiketiyle (çift @
'ye dikkat edin) adreslenebilir.
Ana deponun kanon adı her zaman boş dizedir.
Görünen depo adı
Bir deponun, belirli bir depo bağlamında erişilebilir olduğu ad.
Bu, bir deponun "takma adı" olarak düşünülebilir: michael
kanonik adına sahip depo, alice
deposu bağlamında mike
görünen adına, bob
deposu bağlamında ise mickey
görünen adına sahip olabilir. Bu durumda, michael
içindeki bir hedef, alice
bağlamında @mike//pac/kage:target
etiketiyle adreslenebilir (tek @
'a dikkat edin).
Tersine, bu bir depo eşlemesi olarak da anlaşılabilir: Her depo, "görünür depo adı" ile "kanonik depo adı" arasında bir eşleme sağlar.
Depo kuralı
Bazel'e bir deposu nasıl somutlaştıracağını söyleyen depo tanımları için bir şema. Örneğin, "belirli bir URL'den zip arşivi indirip ayıklayın" veya "belirli bir Maven yapısını getirip java_import
hedefi olarak kullanılabilir hale getirin" ya da basitçe "yerel bir dizine simge bağlantısı oluşturun" 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.
Depo kurallarının en yaygını, bir URL'den arşiv indirip ayıklayan http_archive
ve zaten Bazel deposu olan yerel bir dizine simge bağlantısı oluşturan local_repository
'dir.
Depo getirme
İlişkili repo kuralını çalıştırarak bir repoyu yerel diskte kullanılabilir hale getirme işlemi. Bir çalışma alanında tanımlanan depolar, getirilmeden önce yerel diskte kullanılamaz.
Bazel, genellikle yalnızca repodan bir şeye ihtiyaç duyduğunda ve repo henüz getirilmediğinde repoyu getirir. Depo daha önce getirildiyse Bazel, yalnızca tanımı değiştiyse depoyu yeniden getirir.
Dizin düzeni
Depo, getirildikten sonra çıktı tabanında external
alt dizinindeki kurallı adının altında bulunabilir.
canonical_name
kanonik adıyla deponun içeriğini 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, doğrudan repo tanımlarıyla ç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ü olabilecek bir Bazel projesidir. Her sürüm, bağımlı olduğu diğer modüller hakkında meta veriler yayınlar. Bir modülün, depo kökünde WORKSPACE
dosyasının yanında bir MODULE.bazel
dosyası olmalıdır. Bu dosya, modülün manifest dosyasıdır. Modülün adını, sürümünü, bağımlılık listesini ve diğer bilgilerini belirtir. 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ılarını listelemelidir. Bzlmod, bu bağımlılıkları bir Bazel kayıt defterinde (varsayılan olarak Bazel Merkezi Kayıt Defteri) 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 geçişli bağımlılık grafiğinin tamamını 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 deponun nasıl tanımlanacağını öğ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ını da belirtebilir. Bu veriler, ek depoları tanımlamak için modül çözüldükten sonra modül uzantıları tarafından kullanılır. Bu uzantılar, depo kurallarına benzer özelliklere sahiptir. Bu sayede dosya G/Ç ve ağ isteği gönderme gibi işlemleri gerçekleştirebilirler. Diğerlerinin yanı sıra Bazel'in Bazel modüllerinden oluşturulan bağımlılık grafiğine saygı duyarken diğer paket yönetimi sistemleriyle etkileşim kurmasına olanak tanır.
Bzlmod'daki harici bağlantılar
- bazelbuild/examples'deki Bzlmod kullanım örnekleri
- Bazel Harici Bağımlılıkları İçin Büyük Değişiklik (orijinal Bzlmod tasarım dokümanı)
- BazelCon 2021'de Bzlmod hakkında konuşma
- Bazel Topluluk Günü'nde Bzlmod hakkında konuşma
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 dosyanın söz dizimi, derleme kuralları yerine depo kuralları kullanan BUILD
dosyalarına benzer.
Aşağıdaki snippet, WORKSPACE
dosyasında http_archive
repo kuralının kullanıldığı bir örnektir:
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "foo",
urls = ["https://example.com/foo.zip"],
sha256 = "c9526390a7cd420fdcec2988b4f3626fe9c5b51e2959f685e8f4d170d1a9bd96",
)
Kod snippet'i, kurallı adı foo
olan bir deposu tanımlar. WORKSPACE
sisteminde, varsayılan olarak bir deponun kurallı adı, diğer tüm depolar için görünen adıdır.
WORKSPACE
dosyalarında kullanılabilen işlevlerin tam listesine göz atın.
WORKSPACE
sisteminin eksiklikleri
WORKSPACE
sisteminin kullanıma sunulmasından bu yana geçen yıllarda kullanıcılar aşağıdakiler de dahil olmak üzere birçok sorun yaşadığını bildirdi:
- Bazel, bağımlılıkların
WORKSPACE
dosyalarını değerlendirmez. Bu nedenle, tüm geçişli bağımlılıkların doğrudan bağımlılıklara ek olarak ana deponunWORKSPACE
dosyasında tanımlanması gerekir. - Bu sorunun üstesinden gelmek için projeler "deps.bzl" kalıbını benimsemiş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.- Bunun da kendine özgü sorunları vardır: Makrolar diğer
.bzl
dosyalarınıload
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" makrosu çağırmasını sağlayarak bu sorunu gidermesi gerekir. - Bazel,
WORKSPACE
dosyasını sırayla değerlendirir. Ayrıca, bağımlılıklar herhangi bir sürüm bilgisi olmadan URL'lerle birliktehttp_archive
kullanılarak belirtilir. Bu, elmas bağımlılıklarında (A
,B
veC
'ye bağlıdır;B
veC
,D
'ın farklı sürümlerine bağlıdır) sürüm çözümlemesi yapmanın güvenilir bir yolu olmadığı anlamına gelir.
- Bunun da kendine özgü sorunları vardır: Makrolar diğer
WORKSPACE'in eksiklikleri nedeniyle Bzlmod, gelecekteki Bazel sürümlerinde eski WORKSPACE sisteminin yerini alacak. Bzlmod'a geçiş hakkında lütfen Bzlmod taşıma kılavuzunu okuyun.