Bazel modülü, birden çok sürümü olabilen ve her biri bağımlı olduğu diğer modüller hakkında meta veriler yayınlayan bir Bazel projesidir. Bu; Maven yapısı, npm paketi, Go modülü veya Kargo sandığı gibi diğer bağımlılık yönetimi sistemlerindeki bilinen kavramlara benzer.
Bir modülün deposunda (WORKSPACE
dosyasının yanında) MODULE.bazel
dosyası olmalıdır. Bu dosya, modülün manifest dosyasıdır. Burada dosyanın adı, sürümü, doğrudan bağımlılık listesi ve diğer bilgiler belirtilir. Temel bir örnek olarak:
module(name = "my-module", version = "1.0")
bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")
MODULE.bazel
dosyalarında bulunan yönergelerin tam listesini inceleyin.
Bazel, modül çözünürlüğü gerçekleştirmek için kök modülün MODULE.bazel
dosyasını okuyarak başlar ve ardından bağımlılık grafiğinin tamamını keşfedene kadar Bazel kayıt defterinden bağımlılığın MODULE.bazel
dosyasını sürekli olarak ister.
Varsayılan olarak Bazel daha sonra kullanılacak her bir modülün bir sürümünü seçer. Bazel her modülü bir depoyla temsil eder ve her bir depoyu nasıl tanımlayacağını öğrenmek için kayıt otoritesine tekrar danışır.
Sürüm biçimi
Bazel çeşitlilik içeren bir ekosisteme sahiptir ve projelerde çeşitli sürüm şemaları kullanılmaktadır. Açık farkla en popüler olan SemVer ama versiyonları tarih tabanlı olan Abseil gibi farklı şemaların kullanıldığı önemli projeler de vardır (ör. 20210324.2
).
Bu nedenle Bzlmod, SemVer spesifikasyonunun daha rahat bir sürümünü kullanır. Aradaki farklar şunlardır:
- SemVer, sürümün "yayınlama" bölümünün 3 segmentten oluşması gerektiğini belirtir:
MAJOR.MINOR.PATCH
. Bazel'de bu şart gevşetilerek istenilen sayıda segmente izin verilir. - SemVer'de, "sürüm" bölümündeki her segment yalnızca rakam içermelidir. Bazel'de bu durum harflere izin verilmesi için gevşetildi ve karşılaştırma anlamları, "yayın öncesi" bölümündeki "tanımlayıcılar"la eşleşiyor.
- Ayrıca ana, küçük ve yama sürümü artışlarının anlamları uygulanmaz. Ancak geriye dönük uyumluluğu nasıl gösterdiğimizle ilgili ayrıntılar için uyumluluk düzeyine bakın.
Geçerli herhangi bir SemVer sürümü, geçerli bir Bazel modülü sürümüdür. Ayrıca, iki SemVer sürümü a
ve b
, yalnızca Bazel modül sürümleriyle karşılaştırıldığında aynı muhafazaların geçerli olduğu durumlarda a < b
ile karşılaştırma yapar.
Sürüm seçimi
Sürümlü bağımlılık yönetimi alanının en önemli unsurlarından biri olan elmas bağımlılık sorununu düşünün. Bağımlılık grafiğinin olduğunu varsayalım:
A 1.0
/ \
B 1.0 C 1.1
| |
D 1.0 D 1.1
Hangi D
sürümü kullanılmalıdır? Bzlmod, bu soruyu çözmek için Go modül sisteminde sunulan Minimal Sürüm Seçimi (MVS) algoritmasını kullanır. MVS, bir modülün tüm yeni sürümlerinin geriye dönük uyumlu olduğunu varsayar ve bu nedenle herhangi bir bağımlı tarafından belirtilen en yüksek sürümü seçer (örneğimizde D 1.1
). D 1.1
, gereksinimlerimizi karşılayabilecek en eski sürüm olduğu için "minimal" olarak adlandırılmıştır. D 1.2
veya daha yeni bir sürüm mevcut olsa bile bu sürümleri seçmeyiz. MVS'nin kullanılması, yüksek kaliteli ve yeniden oluşturulabilir bir sürüm seçme süreci oluşturur.
Yanked sürümleri
Kayıt otoritesi, kaçınılması gereken belirli sürümleri (güvenlik açıkları gibi) yankılandı olarak tanımlayabilir. Bazel bir modülün çekilmiş sürümünü
seçirken hata bildiriyor. Bu hatayı düzeltmek için daha yeni, yedeklenmemiş bir sürüme yükseltin veya yankmış sürüme açıkça izin vermek için --allow_yanked_versions
işaretini kullanın.
Uyumluluk düzeyi
Go'da MVS'nin geriye dönük uyumluluk varsayımı, bir modülün geriye dönük uyumsuz sürümlerini ayrı bir modül olarak ele aldığı için işe yarar. SemVer açısından bu, A 1.x
ve A 2.x
'nin ayrı modüller olarak kabul edildiği ve çözülmüş bağımlılık grafiğinde bir arada bulunabileceği anlamına gelir. Böylece bu da Go'daki paket yolunda ana sürümün kodlanmasıyla mümkün olur, böylece derleme zamanı veya bağlantı zamanı çakışması olmaz.
Ancak Bazel, bu tür garantiler veremeyeceğinden geriye dönük uyumsuz sürümlerin algılanabilmesi için "ana sürüm" numarasına ihtiyacı vardır. Bu sayı uyumluluk düzeyi olarak adlandırılır ve her modül sürümü tarafından module()
yönergesinde belirtilir. Bazel bu bilgileri kullanarak aynı modülün farklı uyumluluk düzeylerine sahip sürümlerinin çözülmüş bağımlılık grafiğinde bulunduğunu tespit ettiğinde hata verebilir.
Geçersiz kılar:
Bazel modül çözünürlüğünün davranışını değiştirmek için MODULE.bazel
dosyasında geçersiz kılmaları belirtin. Yalnızca kök modülün geçersiz kılmaları geçerli olur. Modül bağımlılık olarak kullanılıyorsa geçersiz kılmaları yoksayılır.
Her geçersiz kılma işlemi, belirli bir modül adı için belirtilir ve bağımlılık grafiğindeki tüm sürümlerini etkiler. Yalnızca kök modülün geçersiz kılmaları etkili olsa da bunlar, kök modülün doğrudan bağımlı olmadığı geçişli bağımlılıklar için olabilir.
Tek sürümlü geçersiz kılma
single_version_override
birden fazla amaca hizmet eder:
version
özelliği sayesinde, bağımlılık grafiğinde hangi sürümlerin istendiğine bakılmaksızın bağımlılığı belirli bir sürüme sabitleyebilirsiniz.registry
özelliğiyle bu bağımlılığı, normal kayıt otoritesi seçim sürecini uygulamak yerine belirli bir kayıt otoritesinden gelmeye zorlayabilirsiniz.patch*
özellikleriyle, indirilen modüle uygulanacak bir yama grubu belirtebilirsiniz.
Bu özelliklerin tümü isteğe bağlıdır ve birbiriyle karıştırılıp eşleştirilebilir.
Birden çok sürümü geçersiz kılma
Aynı modülün birden çok sürümünün çözümlenen bağımlılık grafiğinde bir arada bulunmasını sağlamak için bir multiple_version_override
belirtilebilir.
Modül için izin verilen sürümlerin açık bir listesini belirtebilirsiniz. Bu liste, çözümlenmeden önce bağımlılık grafiğinde yer almalıdır. İzin verilen her sürüme bağlı olarak bazı geçişli bağımlılıklar bulunmalıdır. Çözünürlükten sonra, yalnızca modülün izin verilen sürümleri kalırken Bazel, modülün diğer sürümlerini aynı uyumluluk düzeyinde izin verilen en yakın sürüme yükseltir. Aynı uyumluluk düzeyinde izin verilen daha yüksek bir sürüm yoksa Bazel bir hata bildirir.
Örneğin, bağımlılık grafiğinde çözümden önce gösterilen 1.1
, 1.3
, 1.5
, 1.7
ve 2.0
sürümleri varsa ve ana sürüm uyumluluk düzeyiyse:
1.3
,1.7
ve2.0
değerlerine izin veren çoklu sürüm geçersiz kılma,1.1
1.3
sürümüne,1.5
ise kalan1.7
sürümlere ve diğer sürümlere yükseltilmesiyle sonuçlanır.1.7
için yükseltme yapılacak aynı uyumluluk düzeyinde daha yüksek bir sürüm olmadığından1.5
ve2.0
uygulamalarına izin veren çoklu sürüm geçersiz kılma işlemi hatayla sonuçlanır.- Çözümden önceki bağımlılık grafiğinde
1.9
olmadığı için1.9
ve2.0
uygulamalarına izin veren birden çok sürümlü bir geçersiz kılma hataya yol açar.
Ayrıca kullanıcılar, tek sürümlü geçersiz kılmalara benzer şekilde, registry
özelliğini kullanarak kayıt defterini de geçersiz kılabilir.
Kayıt otoritesi dışındaki geçersiz kılma işlemleri
Kayıt dışı geçersiz kılma işlemleri, bir modülü sürüm çözünürlüğünden tamamen kaldırır. Bazel, bu MODULE.bazel
dosyalarını bir kayıt defterinden değil, deponun kendisinden ister.
Bazel, aşağıdaki kayıt dışı geçersiz kılma işlemlerini destekler:
Depo adları ve katı dep'ler
Bir modülü destekleyen bir deponun standart adı module_name~version
şeklindedir (örneğin, bazel_skylib~1.0.3
). Kayıt otoritesi olmayan bir geçersiz kılmaya sahip modüllerde version
kısmını override
dizesiyle değiştirin. Standart ad biçiminin güvenmeniz gereken bir API olmadığını ve her an değişebileceğini unutmayın.
Bir modülü doğrudan bağlı öğelerine destekleyen bir deponun görünen adı, bazel_dep
yönergesinin repo_name
özelliği aksini söylemediği sürece varsayılan olarak modül adına ayarlanır. Bunun, bir modülün yalnızca doğrudan bağımlılıklarını
bulabileceği anlamına geldiğini unutmayın. Bu, geçişli bağımlılıklardaki değişikliklerden dolayı kazara ortaya çıkabilecek kesintileri önlemeye yardımcı olur.
Modül uzantıları, bir modülün görünür kapsamına ek depolar da ekleyebilir.