Bazel modülü, her birinin bağlı olduğu diğer modüllerle ilgili meta verileri yayınlayan birden çok sürümü olabilen bir Bazel projesidir. Bu, diğer bağımlılık yönetimi sistemlerindeki (Maven yapı, npm paketi, Go modülü veya kargo kabı) bilinen kavramlara benzer.
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 adını, sürümünü, doğrudan bağımlılıklarının listesini ve diğer bilgileri açıklayan manifest dosyasıdır. Temel bir örnek verecek olursak:
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 kullanılabilen yönergelerin tam listesini inceleyin.
Bazel, modül çözümlemeyi 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 otoritesinden tüm bağımlılıkların MODULE.bazel dosyasını tekrar tekrar ister.
Daha sonra Bazel varsayılan olarak kullanılacak her modülün bir sürümünü seçer. Bazel, her modülü bir depoyla temsil eder ve depoların her birinin nasıl tanımlanacağını öğrenmek için kayıt defterine tekrar başvurur.
Sürüm biçimi
Bazel'in çeşitli bir ekosistemi vardır ve projelerde çeşitli sürümlendirme şemaları kullanılır. Şu ana kadar en popüler olan SemVer olsa da farklı şemaların kullanıldığı önemli projeler de vardır. Örneğin 20210324.2 gibi versiyonları tarih tabanlı olan Abseil).
Bu nedenle Bzlmod, SemVer spesifikasyonunun daha esnek bir sürümünü kullanır. Farklılıklar şunlardır:
- SemVer, sürümün "yayın" bölümünün 3 segmentten oluşması gerektiğini belirtir:
MAJOR.MINOR.PATCH. Bazel'de bu şart, herhangi bir sayıda segmente izin verecek şekilde gevşetilmiştir. - SemVer'de, "sürüm" bölümündeki segmentlerin her biri yalnızca rakamlardan oluşmalıdır. Bazel'de bu, harflere de izin verecek şekilde gevşetilir ve karşılaştırma semantikleri, "ön sürüm" bölümündeki "tanımlayıcılar" ile eşleşir.
- Ayrıca ana, alt ve yama sürümü artışlarının anlamı zorunlu kılınmaz. Ancak geriye dönük uyumluluğu nasıl belirttiğimizle ilgili ayrıntılar için uyumluluk düzeyi bölümüne bakın.
Geçerli tüm SemVer sürümleri geçerli Bazel modülü sürümüdür. Ayrıca, iki SemVer sürümü a ve b, Bazel modülü sürümleri olarak karşılaştırıldığında aynı sonucu verirse ve yalnızca bu durumda a < b ile karşılaştırılır.
Sürüm seçimi
Sürümlü bağımlılık yönetimi alanının vazgeçilmez bir parçası olan elmas bağımlılık problemini düşünün. Aşağıdaki bağımlılığı grafiğiniz olduğunu varsayalım:
A 1.0
/ \
B 1.0 C 1.1
| |
D 1.0 D 1.1
D'nin hangi sürümü kullanılmalıdır? Bzlmod bu sorunu çözmek için Go modül sisteminde tanıtılan Minimum 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ü (örneğimizde D 1.1) seçer. D 1.1, gereksinimlerimizi karşılayabilecek en eski sürüm olduğu için "minimum" olarak adlandırılır. D 1.2 veya daha yeni sürümler olsa bile bunları seçmeyiz. MVS kullanmak, yüksek kaliteli ve yeniden üretilebilir bir sürüm seçim süreci oluşturur.
Yanklanan sürümler
Kaçınılması gereken belirli sürümleri (güvenlik açıkları gibi) kayıt otoritesi yanked olarak bildirebilir. Bazel bir modülün yankılı sürümünü
seçerken hata verir. Bu hatayı düzeltmek için daha yeni ve yankı olmayan bir sürüme geçin veya yanked sürüme açıkça izin vermek için --allow_yanked_versions işaretini kullanın.
Uyumluluk seviyesi
Go'da MVS'nin geriye dönük uyumlulukla ilgili varsayımı, bir modülün geriye dönük uyumlu olmayan 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'ün farklı modüller olarak kabul edildiği ve çözülmüş bağımlılık grafiğinde birlikte bulunabileceği anlamına gelir. Bu da Go'da paket yolunda ana sürümün kodlanmasıyla mümkün olur. Böylece, herhangi bir derleme zamanı veya bağlantı zamanı çakışması olmaz.
Ancak Bazel bu tür garantileri sağlayamadığından geriye dönük uyumsuz sürümleri tespit etmek için "ana sürüm" numarasına ihtiyacı vardır. Bu sayı uyumluluk seviyesi olarak adlandırılır ve module() yönergesindeki her modül sürümü tarafından belirtilir. Bazel, bu bilgilerle, çözülmüş bağımlılık grafiğinde aynı modülün farklı uyumluluk düzeylerine sahip sürümlerinin bulunduğunu tespit ettiğinde hata verebilir.
Geçersiz kılar:
Bazel modül çözümlemesinin davranışını değiştirmek için MODULE.bazel dosyasında geçersiz kılma işlemlerini belirtin. Yalnızca kök modülün geçersiz kılma işlemleri geçerli olur. Bir modül bağımlılık olarak kullanılırsa geçersiz kılma işlemleri dikkate alınmaz.
Her geçersiz kılma, 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ılma işlemleri geçerli olsa da bu geçersiz kılma işlemleri, kök modülün doğrudan bağlı olmadığı geçişli bağımlılar için olabilir.
Tek sürümü geçersiz kılma
single_version_override, birden çok amaca hizmet eder:
versionözelliğiyle, bağımlılığın hangi sürümlerinin bağımlılığı grafiğinde istendiğine bakılmaksızın bir bağımlılığı belirli bir sürüme sabitleyebilirsiniz.registryözelliğiyle, normal kayıt defteri seçim sürecini izlemek yerine bu bağımlılığın belirli bir kayıt defteri tarafından sağlanmasını zorunlu kılabilirsiniz.patch*özellikleriyle, indirilen modüle uygulanacak bir dizi yamayı belirtebilirsiniz.
Bu özelliklerin tümü isteğe bağlıdır ve birbirleriyle karıştırılabilir ve eşleştirilebilir.
Birden çok sürümü geçersiz kılma
Çözüme ulaştırılan bağımlılık grafiğinde aynı modülün birden fazla sürümünün birlikte var olmasına izin vermek için bir multiple_version_override belirtilebilir.
Modül için izin verilen sürümlerin açık bir listesini belirtebilirsiniz. Bu sürümlerin tümü, çözümden önce bağımlılık grafiğinde bulunmalıdır. İzin verilen her sürüme bağlı olarak bir geçişli bağımlılık bulunmalıdır. Çözümleme işleminden sonra, modülün yalnızca izin verilen sürümleri kalır. Bazel ise 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 hata verir.
Örneğin, çözümleme öncesi bağımlılık grafiğinde 1.1, 1.3, 1.5, 1.7 ve 2.0 sürümleri varsa ve büyük sürüm uyumluluk düzeyiyse:
1.3,1.7ve2.0sürümlerine izin veren birden fazla sürümü geçersiz kılma;1.1sürümünün1.3,1.5sürümünün1.7sürümüne ve diğer sürümlerin aynı kalmasıyla sonuçlanır.1.7için aynı uyumluluk düzeyinde yükseltme yapılabilecek daha yüksek bir sürüm olmadığından,1.5ve2.0özelliklerine izin veren birden çok sürümün geçersiz kılınması hatayla sonuçlanır.- Bağımlılık grafiğinde çözümden önce
1.9bulunmadığından1.9ve2.0özelliklerine izin veren birden çok sürümün geçersiz kılınması hatayla sonuçlanır.
Ayrıca kullanıcılar, tek sürüm geçersiz kılma işlemlerine benzer şekilde registry özelliğini kullanarak kayıt defterini geçersiz kılabilir.
Kayıt otoritesi dışı 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, kayıt otoritesi dışındaki aşağıdaki geçersiz kılma işlemlerini destekler:
Kod deposu adları ve katı depolar
Bir modülü destekleyen deponun kanonik adı module_name~version'dir (ör. bazel_skylib~1.0.3). Kayıt defteri dışındaki bir geçersiz kılma içeren modüller için version bölümünü override dizesiyle değiştirin. Standart ad biçiminin, güvenebileceğiniz bir API olmadığını ve her an değişebileceğini unutmayın.
Bir modülü doğrudan bağımlılarına destekleyen bir deponun görünür adı, bazel_dep yönergesinin repo_name özelliği aksini belirtmediği sürece varsayılan olarak modül adıdır. Bu, bir modülün yalnızca doğrudan bağımlılarını bulabileceği anlamına gelir. Bu, geçişli bağımlılıklardaki değişikliklerden kaynaklanan kazayla oluşan kesintileri önlemeye yardımcı olur.
Modül uzantıları, bir modülün görünür kapsamına ek depolar da sağlayabilir.