Bazel modülleri

Sorun bildir Kaynağı göster Gece · 7,4 , 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Bazel modülü, birden fazla sürümü olabilecek bir Bazel projesidir. Her sürüm, bağlı olduğu diğer modüller hakkında meta veriler yayınlar. Bu, Maven öğesi, npm paketi, Go modülü veya Cargo kutusu gibi diğer bağımlılık yönetimi sistemlerindeki bilinen kavramlara benzer.

Bir modülün kod deposu kökünde 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:

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 listesine bakın.

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.

Bazel varsayılan olarak her modülün bir sürümünü seçer tıklayın. 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 çeşitlilik içeren bir ekosisteme sahiptir ve projelerde çeşitli sürüm oluşturma şemaları kullanılmaktadır. İlgili içeriği oluşturmak için kullanılan en popüleri SemVer'dir, ancak çeşitli şemaların kullanıldığı önemli projeler, örneğin Abseil sürümler tarihe dayalıdır (örneğin, 20210324.2).

Bu nedenle, Bzlmod SemVer spesifikasyonunun daha rahat bir sürümünü kullanır. İlgili içeriği oluşturmak için kullanılan farklılıklar şunları içerir:

  • SemVer, “yayınlanan” sürüm bölümü 3'ten oluşmalıdır segmentler: MAJOR.MINOR.PATCH. Bazel'de bu şart gevşetilmiştir. izin verilen belirli bir sayıda segmente izin verilir.
  • SemVer'de, "sürüm"deki segmentlerin her biri kısmı 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 semantikleri 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 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, 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ında temel bir unsur olan elmas bağımlılık sorununu düşünün. Aşağıdaki gibi bir bağımlılık grafiğiniz 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 sorunu çözmek için Go modül sisteminde tanıtılan Minimal Sürüm Seçimi (MVS) algoritmasını kullanır. MVS, tüm yeni içeriklerin sürümleri geriye dönük uyumludur; bu nedenle, en yüksek sürüm olan herhangi bir bağımlı tarafından belirtilir (örneğimizde D 1.1). 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 doğrulukta ve tekrarlanabilir bir sürüm seçme süreci

Yanklanan sürümler

Kayıt defteri, belirli sürümlerin kullanılmasından kaçınılması gerekiyorsa (ör. güvenlik açıkları nedeniyle) bu sürümleri geri çekilmiş olarak tanımlayabilir. Bazel, açılır menüden seçim yaparken yankı uygulanmış sürümü olabilir. Bu hatayı düzeltmek için daha yeni bir sürüme yükseltin yankı olmayan sürümü kullanın veya --allow_yanked_versions işaretini kullanın.

Uyumluluk düzeyi

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 büyük sürümü kodlayarak mümkün kılınmıştır. Böylece derleme veya bağlantı sırasında herhangi bir çakışma yaşanmaz.

Ancak Bazel bu tür garantileri sağlayamadığından "ana sürüme" ihtiyacı vardır sayısını kontrol etmek için kullanır. Bu sayıya uyumluluk düzeyi denir ve her modül sürümü tarafından module() yönergesinde belirtilir. Bu bilgiler kullanıldığında, Bazel bir web sitesini ziyaret eden Aynı modülün sürümlerinin farklı uyumluluk düzeylerine sahip olduğunu algılar mevcuttur.

Geçersiz kılar:

Bazel'in davranışını değiştirmek için MODULE.bazel dosyasında geçersiz kılmaları belirtin modülünü kullanabilirsiniz. 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 tüm modülün bağımlılık grafiğinde görebilirsiniz. Sadece kök modülün geçersiz kılmaları kök modülün sağlamadığı geçişli bağımlılıklar olabilir. bağlıdır.

Tek sürümü geçersiz kılma

single_version_override, birden çok amaca hizmet eder:

  • version özelliğiyle, bir bağımlılığı belirli bir öğeye sabitleyebilirsiniz bağımlılığının hangi sürümlerinin istendiğine bakılmaksızın bağımlılık grafiğidir.
  • registry özelliğiyle, normal kayıt defteri seçim sürecini izlemek yerine bu bağımlılığın belirli bir kayıt defterinden gelmesini zorunlu kılabilirsiniz.
  • patch* özellikleriyle, hangi yamaların uygulanacağını belirleyebilirsiniz indiremezsiniz.

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. çözüm öncesinde bağımlılık grafiğinde bulunmalıdır. İzin verilen her sürüme bağlı olarak bazı geçişli bağımlılıklar. Şu tarihten sonra: çözünürlükte, yalnızca modülün izin verilen sürümleri kalır, Bazel yükseltmeleri modülün diğer sürümlerini, aynı zamanda izin verilen en yakın yüksek sürüme uyumluluk düzeyine sahip. 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.7 ve 2.0'ye izin veren birden fazla sürümün geçersiz kılınması, 1.1'in 1.3, 1.5'in 1.7 sürümüne yükseltilmesine ve diğer sürümlerin aynı kalmasına neden olur.
  • 1.5 ve 2.0'e izin veren birden fazla sürüm geçersiz kılma işlemi, 1.7'nin aynı uyumluluk düzeyinde yükseltilebilecek daha yüksek bir sürümü olmadığı için hatayla sonuçlanır.
  • 1.9 ve 2.0 özelliklerine izin veren birden fazla sürümü geçersiz kılma, aşağıdaki gibi hataya neden olur: Çözüm yapılmadan önceki bağımlılık grafiğinde 1.9 mevcut değil.

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ışındaki geçersiz kılmalar

Kayıt defteri olmayanlar, bir modülü sürüm çözünürlüğünden tamamen kaldırır. Bu durum, geçersiz kılma işlemlerini geçersiz kılar. 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:

Bazel modüllerini temsil etmeyen depoları tanımlama

bazel_dep ile diğer Bazel modüllerini temsil eden depolar tanımlayabilirsiniz. Bazen Bazel modülü olmayan bir depo tanımlamanız gerekir. Örneğin, veri olarak okunacak düz bir JSON dosyası içeren bir depo.

Bu durumda, use_repo_rule yönergesini doğrudan tanımlamak için bunu yapabilirsiniz. Bu kod deposu yalnızca bulunduğu modül tarafından görülebilir tanımlanmalıdır.

Bu özellik, modül uzantılarıyla aynı mekanizma kullanılarak uygulanır. Bu sayede, depoları daha fazla esneklikle tanımlayabilirsiniz.

Depo adları ve katı bağımlılar

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ıkları ifade eder.

Bir modülü destekleyen deposunun kanonik adı, bağımlılık grafiğinin tamamında modülün birden fazla sürümünün olup olmadığına bağlı olarak module_name+version (ör. bazel_skylib+1.0.3) veya module_name+ (ör. bazel_features+) olur (multiple_version_override bölümüne bakın). Kanonik ad biçiminin, güvenebileceğiniz bir API olmadığını ve herhangi bir zamanda değişebileceğini unutmayın. Standart adı sabit kodlamak yerine, doğrudan Bazel'dan almak için desteklenen bir yol kullanın: * BUILD ve .bzl dosyalarında şunu kullanın: Label örneğinde Label.repo_name kod deposunun görünür adı ile verilen bir etiket dizesinden oluşturulur (ör. Label("@bazel_skylib").repo_name. * Çalıştırma dosyalarını ararken $(rlocationpath ...) kitaplıklardan birini @bazel_tools//tools/{bash,cpp,java}/runfiles veya rules_foo kural kümesi için, @rules_foo//foo/runfiles içinde. * Bazel ile IDE veya dil sunucusu gibi harici bir araçtan etkileşime girdiğinizde, belirli bir depo grubu için görünen adlardan standart adlara eşlemeyi almak üzere bazel mod dump_repo_mapping komutunu kullanın.

Modül uzantıları, bir modülün görünür kapsamına ek depolar da ekleyebilir.