WORKSPACE'in eksiklikleri nedeniyle Bzlmod, gelecekteki Bazel sürümlerinde eski WORKSPACE sistemini değiştirecek. Bu kılavuz, projenizi Bzlmod'a taşımanıza ve harici bağımlılıkları getirmek için WORKSPACE'i bırakmanıza yardımcı olur.
WORKSPACE - Bzlmod karşılaştırması
Bazel'in WORKSPACE ve Bzlmod, farklı söz dizimiyle benzer özellikler sunar. Bu bölümde belirli WORKSPACE işlevlerinden Bzlmod'a nasıl geçiş yapılacağı açıklanmaktadır.
Bazel çalışma alanının kökünü tanımlama
WORKSPACE dosyası, bir Bazel projesinin kaynak kökünü işaretler. Bu sorumluluk Bazel 6.3 ve sonraki sürümlerinde MODULE.bazel ile değiştirilir. Bazel'ın 6.3'ten önceki sürümlerinde, çalışma alanı kök dizininizde şuna benzer yorumlarla hâlâ bir WORKSPACE
veya WORKSPACE.bazel
dosyası olmalıdır:
ÇALIŞMA ALANI
# This file marks the root of the Bazel workspace. # See MODULE.bazel for external dependencies setup.
Marketplace'te Bzlmod'u etkinleştirin
.bazelrc
, Bazel'i her çalıştırdığınızda uygulanacak bayraklar ayarlamanızı sağlar. Bzlmod'u etkinleştirmek için --enable_bzlmod
işaretini kullanın ve her komuta uygulanması için common
komutuna uygulayın:
.bazelrc
# Enable Bzlmod for every Bazel command common --enable_bzlmod
Çalışma alanınız için depo adı belirtin
ÇALIŞMA ALANI
workspace
işlevi, çalışma alanınız için depo adını belirtmek amacıyla kullanılır. Bu, çalışma alanındaki bir hedef//foo:bar
için@<workspace name>//foo:bar
olarak referans verilmesini sağlar. Belirtilmezse çalışma alanınız için varsayılan kod deposu adı__main__
olur.## WORKSPACE workspace(name = "com_foo_bar")
Bzlmod
Aynı çalışma alanındaki hedeflere,
@<repo name>
olmadan//foo:bar
söz dizimiyle referans verilmesi önerilir. Ancak eski söz dizimine ihtiyacınız olursa depo adı olarakmodule
işlevi tarafından belirtilen modül adını kullanabilirsiniz. Modül adı gerekli depo adından farklıysa depo adını geçersiz kılmak içinmodule
işlevininrepo_name
özelliğini kullanabilirsiniz.## MODULE.bazel module( name = "bar", repo_name = "com_foo_bar", )
Dış bağımlılıkları Bazel modülleri olarak al
Bağımlılığınız bir Bazel projesiyse Bzlmod'u da benimsediğinde Bazel modülü olarak bu projeye bağımlı olabilirsiniz.
ÇALIŞMA ALANI
WORKSPACE ile Bazel projesinin kaynaklarını indirmek için genellikle
http_archive
veyagit_repository
deposu kuralları kullanılır.## WORKSPACE load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") http_archive( name = "bazel_skylib", urls = ["https://github.com/bazelbuild/bazel-skylib/releases/download/1.4.2/bazel-skylib-1.4.2.tar.gz"], sha256 = "66ffd9315665bfaafc96b52278f57c7e2dd09f5ede279ea6d39b2be471e7e3aa", ) load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace") bazel_skylib_workspace() http_archive( name = "rules_java", urls = ["https://github.com/bazelbuild/rules_java/releases/download/6.1.1/rules_java-6.1.1.tar.gz"], sha256 = "76402a50ae6859d50bd7aed8c1b8ef09dae5c1035bb3ca7d276f7f3ce659818a", ) load("@rules_java//java:repositories.bzl", "rules_java_dependencies", "rules_java_toolchains") rules_java_dependencies() rules_java_toolchains()
Gördüğünüz gibi bu, kullanıcıların geçişli bağımlılıkları bir bağımlılık makrosundan yüklemesi gereken yaygın bir kalıptır. Hem
bazel_skylib
hem derules_java
öğesininplatform
ürününe bağlı olduğunu varsayın.platform
bağımlılığının tam sürümü, makroların sırasına göre belirlenir.Bzlmod
Bzlmod'da, bağımlılığınız Bazel CentralRegistry'de veya özel Bazel kayıt defterinizde mevcut olduğu sürece bir
bazel_dep
yönergesiyle ona güvenebilirsiniz.## MODULE.bazel bazel_dep(name = "bazel_skylib", version = "1.4.2") bazel_dep(name = "rules_java", version = "6.1.1")
Bzlmod, MVS algoritmasını kullanarak Bazel modülü bağımlılıklarını geçişli olarak çözer. Bu nedenle,
platform
için gereken maksimum sürüm otomatik olarak seçilir.
Bazel modülü olarak bir bağımlılığı geçersiz kılma
Kök modül olarak Bazel modülü bağımlılıklarını farklı şekillerde geçersiz kılabilirsiniz.
Daha fazla bilgi için lütfen overrides bölümünü okuyun.
Bazı örnek kullanımları examples deposunda bulabilirsiniz.
Modül uzantılarıyla harici bağımlılıkları getirme
Bağımlılığınız bir Bazel projesi değilse veya henüz herhangi bir Bazel kayıt defterinde mevcut değilse use_repo_rule
veya modül uzantılarını kullanarak tanıtabilirsiniz.
ÇALIŞMA ALANI
http_file
deposu kuralını kullanarak bir dosya indirin.## WORKSPACE load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file") http_file( name = "data_file", url = "http://example.com/file", sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", )
Bzlmod
Bzlmod ile depoları doğrudan örneklendirmek için MODULE.bazel dosyanızda
use_repo_rule
yönergesini kullanabilirsiniz:## MODULE.bazel http_file = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file") http_file( name = "data_file", url = "http://example.com/file", sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", )
Temelde, bu işlem bir modül uzantısı kullanılarak uygulanır. Bir depo kuralını çağırmaktan daha karmaşık bir mantık gerçekleştirmeniz gerekiyorsa modül uzantısını kendiniz de uygulayabilirsiniz. Tanımı bir
.bzl
dosyasına taşımanız gerekir. Bu sayede, taşıma işlemi sırasında tanımı WORKSPACE ile Bzlmod arasında paylaşabilirsiniz.## repositories.bzl load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file") def my_data_dependency(): http_file( name = "data_file", url = "http://example.com/file", sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", )
Bağımlılıklar makrosunu yüklemek için bir modül uzantısı uygulayın. Bunu, makronun aynı
.bzl
dosyasında tanımlayabilirsiniz, ancak eski Bazel sürümleriyle uyumluluğu korumak için bunu ayrı bir.bzl
dosyasında tanımlamak daha iyidir.## extensions.bzl load("//:repositories.bzl", "my_data_dependency") def _non_module_dependencies_impl(_ctx): my_data_dependency() non_module_dependencies = module_extension( implementation = _non_module_dependencies_impl, )
Depoyu kök projede görünür hale getirmek için MODULE.bazel dosyasında modül uzantısının ve deponun kullanımlarını bildirmeniz gerekir.
## MODULE.bazel non_module_dependencies = use_extension("//:extensions.bzl", "non_module_dependencies") use_repo(non_module_dependencies, "data_file")
Modül uzantısıyla çelişen dış bağımlılıkları çözme
Bir proje, çağrı yapanlardan gelen girdilere dayanarak harici depolar sunan bir makro sağlayabilir. Peki bağımlılık grafiğinde birden fazla arayan varsa ve bunlar bir çakışmaya neden olursa ne olur?
foo
projesinin, version
bağımsız değişkenini alan aşağıdaki makroyu sağladığını varsayalım.
## repositories.bzl in foo {:#repositories.bzl-foo}
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
def data_deps(version = "1.0"):
http_file(
name = "data_file",
url = "http://example.com/file-%s" % version,
# Omitting the "sha256" attribute for simplicity
)
ÇALIŞMA ALANI
WORKSPACE ile makroyu
@foo
kaynağından yükleyebilir ve ihtiyacınız olan veri bağımlılığı sürümünü belirtebilirsiniz.@foo
öğesine bağımlı olan ancak veri bağımlılığının farklı bir sürümünü gerektiren başka bir@bar
bağımlılığınızın olduğunu varsayalım.## WORKSPACE # Introduce @foo and @bar. ... load("@foo//:repositories.bzl", "data_deps") data_deps(version = "2.0") load("@bar//:repositories.bzl", "bar_deps") bar_deps() # -> which calls data_deps(version = "3.0")
Bu durumda son kullanıcının, ihtiyaç duyduğu sürümü alabilmek için WORKSPACE'te makroların sırasını dikkatli bir şekilde ayarlaması gerekir. Bu, bağımlılıkları çözmek için makul bir yol sunmadığından WORKSPACE’in en büyük sorunlarından biri.
Bzlmod
Bzlmod ile,
foo
projesinin yazarı, çakışmaları gidermek için modül uzantısını kullanabilir. Örneğin, tüm Bazel modülleri arasında her zaman veri bağımlılığı için gereken maksimum sürümü seçmenin mantıklı olduğunu varsayalım.## extensions.bzl in foo load("//:repositories.bzl", "data_deps") data = tag_class(attrs={"version": attr.string()}) def _data_deps_extension_impl(module_ctx): # Select the maximal required version in the dependency graph. version = "1.0" for mod in module_ctx.modules: for data in mod.tags.data: version = max(version, data.version) data_deps(version) data_deps_extension = module_extension( implementation = _data_deps_extension_impl, tag_classes = {"data": data}, )
## MODULE.bazel in bar bazel_dep(name = "foo", version = "1.0") foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension") foo_data_deps.data(version = "3.0") use_repo(foo_data_deps, "data_file")
## MODULE.bazel in root module bazel_dep(name = "foo", version = "1.0") bazel_dep(name = "bar", version = "1.0") foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension") foo_data_deps.data(version = "2.0") use_repo(foo_data_deps, "data_file")
Bu durumda, kök modül
2.0
veri sürümünü gerektirirkenbar
bağımlılığı için3.0
gerekir.foo
üzerindeki modül uzantısı bu çakışmayı doğru şekilde çözebilir ve veri bağımlılığı için otomatik olarak3.0
sürümünü seçebilir.
Üçüncü taraf paket yöneticisini entegre et
Son bölümden sonra, modül uzantısı bağımlılık grafiğinden bilgi toplamak, bağımlılıkları çözmek için özel mantık uygulamak ve harici depolar eklemek amacıyla kod deposu kurallarını çağırmak için bir yol sağladığından, bu yöntem kural yazarlarının belirli diller için paket yöneticilerini entegre eden kural kümelerini geliştirmeleri için mükemmel bir yol sağlar.
Modül uzantılarının nasıl kullanılacağı hakkında daha fazla bilgi edinmek için lütfen modül uzantıları sayfasını okuyun.
Farklı paket yöneticilerinden bağımlılıkları getirmek için Bzlmod'u kullanmakta olan kural kümelerinin listesini aşağıda bulabilirsiniz:
Sözde paket yöneticisini entegre eden minimal bir örneği examples deposunda bulabilirsiniz.
Ana makinedeki araç zincirlerini algılama
Bazel derleme kurallarının ana makine makinenizde hangi araç zincirlerinin mevcut olduğunu algılaması gerektiğinde, ana makineyi incelemek ve araç zinciri bilgilerini harici depolar olarak oluşturmak için depo kuralları kullanır.
ÇALIŞMA ALANI
Kabuk araç zincirini algılamak için aşağıdaki depo kuralı verilmiştir.
## local_config_sh.bzl def _sh_config_rule_impl(repository_ctx): sh_path = get_sh_path_from_env("SH_BIN_PATH") if not sh_path: sh_path = detect_sh_from_path() if not sh_path: sh_path = "/shell/binary/not/found" repository_ctx.file("BUILD", """ load("@bazel_tools//tools/sh:sh_toolchain.bzl", "sh_toolchain") sh_toolchain( name = "local_sh", path = "{sh_path}", visibility = ["//visibility:public"], ) toolchain( name = "local_sh_toolchain", toolchain = ":local_sh", toolchain_type = "@bazel_tools//tools/sh:toolchain_type", ) """.format(sh_path = sh_path)) sh_config_rule = repository_rule( environ = ["SH_BIN_PATH"], local = True, implementation = _sh_config_rule_impl, )
Depo kuralını WORKSPACE'te yükleyebilirsiniz.
## WORKSPACE load("//:local_config_sh.bzl", "sh_config_rule") sh_config_rule(name = "local_config_sh")
Bzlmod
Bzlmod ile son bölümde
@data_file
deposunu tanıtmaya benzer şekilde, bir modül uzantısı kullanarak aynı depoyu tanıtabilirsiniz.## local_config_sh_extension.bzl load("//:local_config_sh.bzl", "sh_config_rule") sh_config_extension = module_extension( implementation = lambda ctx: sh_config_rule(name = "local_config_sh"), )
Daha sonra, MODULE.bazel dosyasındaki uzantıyı kullanın.
## MODULE.bazel sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension") use_repo(sh_config_ext, "local_config_sh")
Araç zincirlerini ve yürütme platformlarını kaydedin
Son bölümün ardından, araç zinciri bilgilerini (ör. local_config_sh
) barındıran bir depoyu tanıttıktan sonra muhtemelen araç zincirini kaydetmek istersiniz.
ÇALIŞMA ALANI
WORKSPACE ile araç zincirini aşağıdaki şekillerde kaydedebilirsiniz.
Araç zincirini
.bzl
dosyasına kaydedip makroyu WORKSPACE dosyasına yükleyebilirsiniz.## local_config_sh.bzl def sh_configure(): sh_config_rule(name = "local_config_sh") native.register_toolchains("@local_config_sh//:local_sh_toolchain")
## WORKSPACE load("//:local_config_sh.bzl", "sh_configure") sh_configure()
Alternatif olarak araç zincirini doğrudan WORKSPACE dosyasına kaydedin.
## WORKSPACE load("//:local_config_sh.bzl", "sh_config_rule") sh_config_rule(name = "local_config_sh") register_toolchains("@local_config_sh//:local_sh_toolchain")
Bzlmod
Bzlmod ile
register_toolchains
veregister_execution_platforms
API'leri yalnızca MODULE.bazel dosyasında kullanılabilir. Modül uzantısındanative.register_toolchains
çağıramazsınız.## MODULE.bazel sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension") use_repo(sh_config_ext, "local_config_sh") register_toolchains("@local_config_sh//:local_sh_toolchain")
WORKSPACE
ve WORKSPACE.bzlmod
içinde kaydedilen araç zincirleri ve yürütme platformları ile her Bazel modülünün MODULE.bazel
dosyası, araç zinciri seçimi sırasında şu öncelik sırasını izler (en yüksekten en düşüğe):
- kök modülün
MODULE.bazel
dosyasında kayıtlı araç zincirleri ve yürütme platformları olabilir. WORKSPACE
veyaWORKSPACE.bzlmod
dosyasında kayıtlı araç zincirleri ve yürütme platformları olabilir.- kök modülün (geçişli) bağımlılığı olan modüller tarafından kaydedilmiş araç zincirleri ve yürütme platformları bulunur.
WORKSPACE.bzlmod
kullanılmadığında:WORKSPACE
son eke kayıtlı araç zincirleri.
Yerel depoları kullanıma sunun
Hata ayıklama için bağımlılığın yerel bir sürümüne ihtiyacınız olduğunda veya çalışma alanınıza harici depo olarak bir dizin eklemek istediğinizde bağımlılığı yerel depo olarak eklemeniz gerekebilir.
ÇALIŞMA ALANI
WORKSPACE ile bu, iki yerel depo kuralıyla (
local_repository
venew_local_repository
) gerçekleştirilir.## WORKSPACE local_repository( name = "rules_java", path = "/Users/bazel_user/workspace/rules_java", )
Bzlmod
Bzlmod ile bir modülü yerel bir yolla geçersiz kılmak için
local_path_override
kullanabilirsiniz.## MODULE.bazel bazel_dep(name = "rules_java") local_path_override( module_name = "rules_java", path = "/Users/bazel_user/workspace/rules_java", )
Modül uzantılı yerel bir depoyu kullanıma sunmak da mümkündür. Ancak modül uzantısında
native.local_repository
çağrısı yapılamaz. Tüm yerel depo kurallarına yıldızlar eklemek için devam eden bir çalışma var (ilerleme durumu için #18285'e bakın). Daha sonra, bir modül uzantısında karşılık gelen starlarklocal_repository
öğesini çağırabilirsiniz. Bu sizin için sorun teşkil ediyorsalocal_repository
kod deposu kuralının özel bir sürümünü uygulamak da çok önemlidir.
Hedefleri bağla
WORKSPACE'teki bind
kuralı kullanımdan kaldırıldı ve Bzlmod'da desteklenmiyor. Özel //external
paketinde bir hedefe bir takma ad vermek için kullanıma sunulmuştur. Buna bağlı olan tüm kullanıcıların hesabı taşınmalıdır.
Örneğin
## WORKSPACE
bind(
name = "openssl",
actual = "@my-ssl//src:openssl-lib",
)
Bu, diğer hedeflerin //external:openssl
kaynağına bağımlı olmasına olanak tanır. Bu durumdan başka bir hesaba
geçiş yapmak için şunları yapabilirsiniz:
//external:openssl
öğesinin tüm kullanımlarını@my-ssl//src:openssl-lib
ile değiştirin.İsterseniz
alias
derleme kuralını da kullanabilirsinizAşağıdaki hedefi bir pakette tanımlayın (ör.
//third_party
)## third_party/BUILD alias( name = "openssl", actual = "@my-ssl//src:openssl-lib", )
Tüm
//external:openssl
kullanımlarını//third_party:openssl
ile değiştir.
Getirme ve Senkronizasyon
Getirme ve senkronize etme komutları, harici depoları yerel olarak indirmek ve güncel tutmak için kullanılır. Bazen bir derleme için gereken tüm depoları getirdikten sonra --nofetch
işaretini kullanarak çevrimdışı derlemeye de izin verebilirsiniz.
ÇALIŞMA ALANI
Senkronizasyon, tüm kod depoları veya yapılandırılmış belirli bir depo grubu için zorla getirme işlemi gerçekleştirir. Getirme ise yalnızca belirli bir hedefi getirmek için kullanılır.
Bzlmod
Senkronizasyon komutu artık geçerli değildir ancak getirme işlevi çeşitli seçenekler sunar. Bağımlılık çözümlemeniz ve modül uzantılarınızda yer alan bir hedefi, kod deposunu, yapılandırılmış bir depo kümesini veya tüm depoları getirebilirsiniz. Getirme sonucu önbelleğe alınır. Getirmeyi zorunlu kılmak için getirme işlemi sırasında
--force
seçeneğini eklemeniz gerekir.
Taşıma
Bu bölümde, Bzlmod geçiş sürecinizle ilgili yararlı bilgiler ve yol gösterici bilgiler sağlanmaktadır.
WORKSPACE'teki bağımlılıklarınızı bilin
Taşıma işleminin ilk adımı, hangi bağımlılıklarınız olduğunu anlamaktır. Geçişli bağımlılıklar genellikle *_deps
makrolarıyla yüklendiğinden, WORKSPACE dosyasında tam bağımlılıkların tam olarak hangisine yerleştirildiğini anlamak zor olabilir.
Çalışma alanı çözümlenmiş dosyasıyla harici bağımlılığı inceleyin
Neyse ki, --experimental_repository_resolved_file
işareti size yardımcı olabilir. Bu işaret temelde, son Bazel komutunuzda getirilen tüm harici bağımlılıkların bir "kilit dosyasını" oluşturur. Bu blog yayınında daha ayrıntılı bilgi edinebilirsiniz.
İki şekilde kullanılabilir:
Belirli hedefleri oluşturmak için gereken dış bağımlılıklarla ilgili bilgileri getirmek.
bazel clean --expunge bazel build --nobuild --experimental_repository_resolved_file=resolved.bzl //foo:bar
WORKSPACE dosyasında tanımlanan tüm harici bağımlılıkların bilgilerini getirmek için.
bazel clean --expunge bazel sync --experimental_repository_resolved_file=resolved.bzl
bazel sync
komutuyla, WORKSPACE dosyasında tanımlanan aşağıdakiler dahil tüm bağımlılıkları getirebilirsiniz:bind
kullanımlarıregister_toolchains
veregister_execution_platforms
kullanımları
Ancak projeniz platformlar arası ise bazı depo kuralları yalnızca desteklenen platformlarda doğru şekilde çalışabileceğinden Bazel senkronizasyonu belirli platformlarda kesintiye uğrayabilir.
Komutu çalıştırdıktan sonra harici bağımlılıklarınızla ilgili bilgileri resolved.bzl
dosyasında bulabilirsiniz.
bazel query
ile harici bağımlılığı inceleyin
bazel query
ürününün,
bazel query --output=build //external:<repo name>
Daha kullanışlı ve çok daha hızlı olsa da bazel sorgusu, dış bağımlılık sürümü hakkında bilgi içerebilir. Bu yüzden bu sürümü kullanırken dikkatli olun. Dış bağımlılıkları Bzlmod ile sorgulama ve inceleme işlemleri yeni bir alt komut ile gerçekleştirilecektir.
Yerleşik varsayılan bağımlılıklar
--experimental_repository_resolved_file
tarafından oluşturulan dosyayı kontrol ederseniz WORKSPACE sayfanızda tanımlanmamış birçok bağımlılık bulursunuz.
Bunun nedeni Bazel'in, genellikle yerel kurallar (ör. @bazel_tools
, @platforms
ve @remote_java_tools
) tarafından zorunlu kılınan bazı varsayılan bağımlılıkları eklemek için kullanıcının WORKSPACE dosyası içeriğine önekler ve sonekler eklemesidir. Bzlmod ile bu bağımlılıklar, diğer tüm Bazel modülleri için varsayılan bir bağımlılık olan yerleşik bir modül bazel_tools
ile kullanıma sunulur.
Kademeli geçiş için karma mod
Bzlmod ve WORKSPACE yan yana çalışabilir. Bu da bağımlılıkların WORKSPACE dosyasından Bzlmod'a taşınmasının kademeli bir süreç olmasını sağlar.
WORKSPACE.bzlmod
Taşıma sırasında Bazel kullanıcılarının, Bzlmod etkin olan ve olmayan derlemeler arasında geçiş yapması gerekebilir. Süreci daha sorunsuz hale getirmek için WORKSPACE.bzlmod desteği uygulanmıştır.
WORKSPACE.bzlmod, WORKSPACE ile tam olarak aynı söz dizimine sahiptir. Bzlmod etkinleştirildiğinde WORKSPACE.bzlmod dosyası da çalışma alanı kök dizininde bulunuyorsa:
WORKSPACE.bzlmod
yürürlüğe girer veWORKSPACE
içeriği yok sayılır.- WORKSPACE.bzlmod dosyasına herhangi bir önek veya sonek eklenmez.
WORKSPACE.bzlmod dosyasını kullanmak, aşağıdaki nedenlerden dolayı taşıma işlemini kolaylaştırabilir:
- Bzlmod devre dışı bırakıldığında bağımlılıkları orijinal WORKSPACE dosyasından getirirsiniz.
- Bzlmod etkinleştirildiğinde WORKSPACE.bzlmod ile taşınacak bağımlılıkları daha iyi takip edebilirsiniz.
Depo görünürlüğü
Bzlmod, belirli bir depodan hangi diğer depoların görülebileceğini kontrol edebilir. Daha fazla ayrıntı için depo adlarını ve katı derinlikleri kontrol edin.
WORKSPACE'i de hesaba katarak farklı depo türlerindeki depo görünürlüklerinin özetini aşağıda bulabilirsiniz.
Ana depodan | Bazel modül depolarından | Modül uzantı kod depolarından | WORKSPACE depolarından | |
---|---|---|---|---|
Ana depo | Gösteriliyor | Kök modül doğrudan bağımlılıksa | Kök modül, modül uzantısını barındıran modülün doğrudan bağımlılığıysa | Gösteriliyor |
Bazel modül havuzları | Doğrudan işlemler | Doğrudan uçuşlar | Modül uzantısını barındıran modülün doğrudan bölümleri | Kök modülün doğrudan sürümleri |
Modül uzantı depoları | Doğrudan uçuşlar | Doğrudan uçuşlar | Modül uzantısını barındıran modülün doğrudan konumları + aynı modül uzantısı tarafından oluşturulan tüm depolar | Kök modülün doğrudan sürümleri |
WORKSPACE Kod Depoları | Tümü görünür | Görünmez | Görünmez | Tümü görünür |
@bar
Taşıma süreci
Tipik bir Bzlmod taşıma süreci şu şekilde görünebilir:
- WORKSPACE'te hangi bağımlılıklarınız olduğunu anlayın.
- Proje kök klasörünüze boş bir MODULE.bazel dosyası ekleyin.
- WORKSPACE dosya içeriğini geçersiz kılmak için boş bir WORKSPACE.bzlmod dosyası ekleyin.
- Bzlmod etkin durumdayken hedeflerinizi oluşturun ve hangi deponun eksik olduğunu kontrol edin.
- Çözülmüş bağımlılık dosyasındaki eksik deponun tanımını kontrol edin.
- Eksik bağımlılığı Bazel modülü veya modül uzantısı aracılığıyla sunun ya da daha sonra taşıma işlemi için WORKSPACE.bzlmod içinde bırakın.
- 4’e geri dönün ve tüm bağımlılıklar kullanılabilir hale gelene kadar tekrarlayın.
Taşıma aracı
Başlamanıza yardımcı olabilecek etkileşimli bir Bzlmod taşıma yardımcı komut dosyası vardır.
Komut dosyası şunları yapar:
- WORKSPACE çözümlenen dosyasını oluşturun ve ayrıştırın.
- Çözümlenen dosyadaki depo bilgilerini kullanıcıların okuyabileceği bir şekilde yazdırın.
- Bazel derleme komutunu çalıştırın, tanınan hata mesajlarını tespit edin ve taşıma için bir yöntem önerin.
- BCR'de bir bağımlılığın zaten mevcut olup olmadığını kontrol edin.
- MODULE.bazel dosyasına bir bağımlılık ekleyin.
- Modül uzantısı aracılığıyla bağımlılık ekleyin.
- WORKSPACE.bzlmod dosyasına bir bağımlılık ekleyin.
Kullanabilmek için en son Bazel sürümünün yüklü olduğundan emin olun ve aşağıdaki komutu çalıştırın:
git clone https://github.com/bazelbuild/bazel-central-registry.git
cd <your workspace root>
<BCR repo root>/tools/migrate_to_bzlmod.py -t <your build targets>
Bazel modüllerini yayınla
Bazel projeniz başka projelere bağımlıysa projenizi Bazel Central Registry'de yayınlayabilirsiniz.
BCR'de projenizi kontrol edebilmek için projenin kaynak arşiv URL'sine ihtiyacınız vardır. Kaynak arşivi oluştururken birkaç noktaya dikkat edin:
Arşivin belirli bir sürümü işaret ettiğinden emin olun.
Bzlmod'un bağımlılık çözümü sırasında sürüm karşılaştırması yürütmesi gerektiğinden, BCR yalnızca sürümü oluşturulmuş kaynak arşivleri kabul edebilir.
Arşiv URL'sinin sabit olduğundan emin olun.
Bazel, arşivin içeriğini bir karma değeriyle doğrular. Bu nedenle, indirilen dosyanın sağlama toplamının hiçbir zaman değişmediğinden emin olmanız gerekir. URL, GitHub'dan geliyorsa lütfen sürüm sayfasında bir sürüm arşivi oluşturup yükleyin. GitHub, isteğe bağlı olarak oluşturulan kaynak arşivlerin sağlama toplamını garanti etmez. Kısacası,
https://github.com/<org>/<repo>/releases/download/...
biçimindeki URL'ler kararlı olarak kabul edilirkenhttps://github.com/<org>/<repo>/archive/...
değildir. Daha fazla bağlam için GitHub Arşiv Sağlama Toplamı Kesintisi'ne göz atın.Kaynak ağacının, orijinal kod deposunun düzenine uyduğundan emin olun.
Deponuz çok büyükse ve gereksiz kaynakları çıkararak daha küçük boyutlu bir dağıtım arşivi oluşturmak istiyorsanız lütfen sadeleştirilmiş kaynak ağacının orijinal kaynak ağacının bir alt kümesi olduğundan emin olun. Bu, son kullanıcıların
archive_override
vegit_override
aracılığıyla modülü yayın dışı bir sürüme geçirmelerini kolaylaştırır.En yaygın API'lerinizi test eden bir alt dizine bir test modülü ekleyin.
Test modülü, yayınlanacak asıl modüle bağlı olarak kaynak arşivinin bir alt dizininde bulunan kendi WORKSPACE ve MODULE.bazel dosyasına sahip bir Bazel projesidir. Test, en yaygın API'lerinizi kapsayan örnekler veya bazı entegrasyon testleri içermelidir. Nasıl oluşturulacağını öğrenmek için test modülünü inceleyin.
Kaynak arşiv URL'niz hazır olduğunda, modülünüzü bir GitHub Pull İsteği ile BCR'ye göndermek için BCR katkı kurallarını uygulayın.
Modülünüzü BCR'ye gönderme sürecini otomatikleştirmek amacıyla deponuz için Publish to BCR GitHub uygulamasını ayarlamanız önemle tavsiye edilir.
En iyi uygulamalar
Bu bölümde, dış bağımlılıklarınızı daha iyi yönetmek için izlemeniz gereken birkaç en iyi uygulama açıklanmaktadır.
Gereksiz bağımlılıkları getirmekten kaçınmak için hedefleri farklı paketlere bölün.
Testlere yönelik geliştirici bağımlılıklarının, bunlara ihtiyacı olmayan derleme hedefleri için gereksiz yere getirilmesine zorlandığı #12835 bölümünü kontrol edin. Bu aslında Bzlmod'a özgü değildir ancak bu uygulamaların izlenmesi geliştirici bağımlılıklarını doğru şekilde belirtmeyi kolaylaştırır.
Geliştirici bağımlılıklarını belirtin
bazel_dep
ve use_extension
yönergeleri için dev_dependency
özelliğini "true" olarak ayarlayabilirsiniz. Böylece bu yönerge, bağımlı projelere yayılmaz. Kök modül olarak, hedeflerinizin hâlâ geliştirici bağımlıları olmadan derlenip derlenmediğini doğrulamak için --ignore_dev_dependency
işaretini kullanabilirsiniz.
Topluluk taşıma işlemi ilerleme durumu
Bağımlılıklarınızın hâlihazırda mevcut olup olmadığını öğrenmek için Bazel Central Registry'ye göz atabilirsiniz. Aksi takdirde, taşıma işleminizi engelleyen bağımlılıkları onaylamak veya yayınlamak için bu GitHub tartışmasına katılabilirsiniz.
Sorun bildirme
Bilinen Bzlmod sorunları için lütfen Bazel GitHub sorun listesini kontrol edin. Geçişin önündeki engelleri kaldırmanızı sağlayabilecek yeni sorunlar veya özellik istekleri göndermekten çekinmeyin.