Sık sorulan sorular

Sorun bildirme Kaynağı görüntüleme Nightly · 8.2 · 8.1 · 8.0 · 7.6 · 7.5

Bu sayfada, Bazel'deki harici bağımlılıklarla ilgili sık sorulan bazı sorulara yanıt verilmektedir.

MODULE.bazel

MODULE.bazel neden load dosyalarını desteklemiyor?

Bağımlılık çözümleme sırasında, referans verilen tüm harici bağımlılıkların MODULE.bazel dosyası kayıt defterilerden alınır. Bu aşamada, bağımlılıkların kaynak arşivleri henüz getirilmemiştir. Dolayısıyla MODULE.bazel dosyası loadbaşka bir dosyaysa Bazel'in kaynak arşivinin tamamını getirmeden bu dosyayı getirmesi mümkün değildir. MODULE.bazel dosyasının doğrudan kayıt defterinde barındırıldığı için özel olduğunu unutmayın.

MODULE.bazel dosyasında load isteyen kullanıcıların genellikle ilgilendiği birkaç kullanım alanı vardır ve bunlar load olmadan çözülebilir:

  • MODULE.bazel dosyasında listelenen sürümün, başka bir yerde (ör. .bzl dosyasında) depolanan derleme meta verileriyle tutarlı olmasını sağlama: Bu, BUILD dosyasından yüklenen bir .bzl dosyasında native.module_version yöntemi kullanılarak yapılabilir.
  • Özellikle tek depolarda çok büyük MODULE.bazel dosyalarını yönetilebilir bölümlere ayırma: Kök modül, MODULE.bazel dosyasını birden fazla segmente bölmek için include yönergesini kullanabilir. MODULE.bazel dosyalarında load'lere izin vermediğimiz için include, kök olmayan modüllerde kullanılamaz.
  • Eski WORKSPACE sistemini kullananlar, bir depo tanımladıktan sonra karmaşık mantık yürütmek için hemen bu depodan loadaldığını hatırlayabilir. Bu özellik, modül uzantılarıyla değiştirildi.

bazel_dep için SemVer aralığı belirtebilir miyim?

Hayır. npm ve Cargo gibi diğer bazı paket yöneticileri sürüm aralıklarını (dolaylı veya açıkça) destekler. Bu genellikle bir kısıtlama çözücü gerektirir (kullanıcılar için çıktının tahmin edilmesini zorlaştırır) ve sürüm çözümlemesini kilit dosyası olmadan yeniden üretilemez hale getirir.

Bazel bunun yerine Go gibi Minimum Sürüm Seçimi'ni kullanır. Bu, aksine çıktının tahmin edilmesini kolaylaştırır ve yeniden üretilebilirliği garanti eder. Bu, Bazel'in tasarım hedefleriyle eşleşen bir değiş tokuştur.

Ayrıca Bazel modül sürümleri SemVer'in bir üst kümesidir. Bu nedenle, katı bir SemVer ortamında mantıklı olan her şey Bazel modül sürümlerine her zaman aktarılmaz.

bazel_dep için en son sürümü otomatik olarak alabilir miyim?

Bazı kullanıcılar, bir depin en son sürümünü otomatik olarak almak için bazel_dep(name = "foo", version = "latest") belirtme olanağı sunmamızı ister. Bu, SemVer aralıkları hakkındaki soruya benzer ve yanıtı da "hayır"dır.

Burada önerilen çözüm, bu işlemin otomasyon tarafından yapılmasıdır. Örneğin, Renovate Bazel modüllerini destekler.

Bu soruyu soran kullanıcılar bazen yerel geliştirme sırasında hızlı bir şekilde iterasyon yapmanın bir yolunu arıyor olabilir. Bu işlem, local_path_override kullanılarak yapılabilir.

Neden bu kadar çok use_repo var?

MODULE.bazel dosyalarındaki modül uzantısı kullanımları bazen büyük bir use_repo yönergesi ile birlikte gelir. Örneğin, gazelle'daki go_deps uzantısının tipik kullanımı şu şekilde olabilir:

go_deps = use_extension("@gazelle//:extensions.bzl", "go_deps")
go_deps.from_file(go_mod = "//:go.mod")
use_repo(
    go_deps,
    "com_github_gogo_protobuf",
    "com_github_golang_mock",
    "com_github_golang_protobuf",
    "org_golang_x_net",
    ...  # potentially dozens of lines...
)

Bilgiler referans verilen go.mod dosyasında zaten bulunduğundan uzun use_repo yönergesi gereksiz görünebilir.

Bazel'in bu use_repo yönergesine ihtiyacı, modül uzantılarını tembelce çalıştırmasından kaynaklanır. Yani bir modül uzantısı yalnızca sonucu gözlemlenirse çalıştırılır. Modül uzantısının "çıktısı" depo tanımları olduğundan, bir modül uzantısı yalnızca tanımladığı bir depo istenirse çalıştırılır (örneğin, yukarıdaki örnekte hedef @org_golang_x_net//:foo derlenirse). Ancak bir modül uzantısının hangi depoları tanımlayacağını çalıştırana kadar bilemeyiz. Bu noktada use_repo yönergesi devreye girer. Kullanıcı, Bazel'e uzantının hangi depoları oluşturmasını beklediğini söyleyebilir. Bazel de uzantıyı yalnızca bu depoların kullanıldığı durumlarda çalıştırır.

Bu use_repo yönergesinin korunmasına yardımcı olmak için modül uzantısı, uygulama işlevinden bir extension_metadata nesnesi döndürebilir. Kullanıcı, bu modül uzantılarının use_repo yönergelerini güncellemek için bazel mod tidy komutunu çalıştırabilir.

Bzlmod taşıma

Önce hangisi değerlendirilir: MODULE.bazel mi yoksa WORKSPACE mi?

Hem --enable_bzlmod hem de --enable_workspace ayarlandığında, önce hangi sisteme danışıldığını merak etmek normaldir. Kısa yanıt, MODULE.bazel'in (Bzlmod) önce değerlendirildiğidir.

Uzun cevabı şudur: "Hangisi önce değerlendirilir?" sorusunun yerine şu soruyu sormanız gerekir: Kanonik adı @@foo olan depo bağlamında, görünür depo adı @bar neyi ifade eder? Alternatif olarak, @@base için hangi depo eşlemesi kullanılıyor?

Açık repo adlarına sahip etiketler (öncesinde tek bir @), çözümlendikleri bağlama göre farklı şeylere atıfta bulunabilir. @bar//:baz etiketini gördüğünüzde aslında neyi gösterdiğini merak ederseniz önce bağlam deposunun ne olduğunu bulmanız gerekir. Örneğin, etiket @@foo deposunda bulunan bir BUILD dosyasındaysa bağlam deposu @@foo'dur.

Ardından, içerik deposunun ne olduğuna bağlı olarak, görünür bir adın aslında hangi depoya yönlendirildiğini öğrenmek için taşıma kılavuzundaki "repository visibility" tablosu kullanılabilir.

  • Bağlam deposu ana depo ise (@@):
    1. bar, kök modülün MODULE.bazel dosyası tarafından tanıtılan (bazel_dep, use_repo, module, use_repo_rule seçeneklerinden herhangi biri aracılığıyla) görünen bir depo adıysa @bar, MODULE.bazel dosyasının iddia ettiği değere çözümlenir.
    2. Aksi takdirde, bar WORKSPACE'te tanımlanmış bir depoysa (yani normal adı @@bar ise) @bar, @@bar olarak çözümlenir.
    3. Aksi takdirde @bar, @@[unknown repo 'bar' requested from @@] gibi bir değere çözümlenir ve bu da sonuçta hatayla sonuçlanır.
  • Bağlama depolama alanı bir Bzlmod-dünya depolama alanıysa (yani kök olmayan bir Bazel modülüne karşılık gelirse veya bir modül uzantısı tarafından oluşturulursa) yalnızca diğer Bzlmod-dünya depolama alanlarını görür ve WORKSPACE-dünya depolama alanlarını görmez.
    • Özellikle, kök modüldeki non_module_deps benzeri bir modül uzantısında veya kök modüldeki use_repo_rule örneklemelerinde tanıtılan tüm depolar buna dahildir.
  • Bağlam deposu WORKSPACE'te tanımlanmışsa:
    1. Öncelikle, bağlam deposu tanımında sihirli repo_mapping özelliğinin olup olmadığını kontrol edin. Bu durumda, önce eşlemeyi inceleyin (repo_mapping = {"@bar": "@baz"} ile tanımlanan bir depo için aşağıdaki @baz değerine bakarız).
    2. bar, kök modülün MODULE.bazel dosyası tarafından tanıtılan görünür bir depo adıysa @bar, MODULE.bazel dosyasının belirttiği değere çözümlenir. (Bu, ana repo destek kaydındaki 1. öğeyle aynıdır.)
    3. Aksi takdirde @bar, @@bar olarak çözümlenir. Bu, büyük olasılıkla WORKSPACE içinde tanımlanmış bir bar deposunu gösterir. Böyle bir depo tanımlanmamışsa Bazel hata verir.

Daha kısa bir sürüm için:

  • Bzlmod-world depoları (ana depo hariç) yalnızca Bzlmod-world depolarını görür.
  • WORKSPACE-world depoları (ana depo dahil) önce Bzlmod dünyasındaki kök modülün neyi tanımladığını görür, ardından WORKSPACE-world depolarını görmeye geri döner.

Bazel komut satırındaki etiketlerin (Starlark işaretleri, etiket türündeki işaret değerleri ve derleme/test hedefi kalıpları dahil) bağlam deposu olarak ana depoya sahip olduğu kabul edilir.

Diğer

Nasıl çevrimdışı derleme hazırlayıp çalıştırabilirim?

Depoları önceden almak için bazel fetch komutunu kullanın. Yalnızca @foo deposunu (ana depo bağlamında çözülür, yukarıdaki soruya bakın) almak için --repo işaretini (bazel fetch --repo @foo gibi) veya @foo//:bar'nin tüm geçişli bağımlılıkları (bazel build --nobuild @foo//:bar ile eşdeğerdir) almak için bir hedef kalıbı (bazel fetch @foo//:bar gibi) kullanabilirsiniz.

Derleme sırasında hiçbir getirme işlemi yapılmadığından emin olmak için --nofetch kullanın. Daha açık belirtmek gerekirse, bu durum yerel olmayan bir depo kuralı çalıştırma girişimlerinin başarısız olmasına neden olur.

Depoları almak ve yerel olarak test etmek için değiştirmek istiyorsanız bazel vendor komutunu kullanabilirsiniz.

HTTP proxy'leri nasıl kullanırım?

Bazel, curl gibi diğer programlar tarafından yaygın olarak kabul edilen http_proxy ve HTTPS_PROXY ortam değişkenlerine uyar.

Bazel'in çift yığınlı IPv4/IPv6 kurulumlarında IPv6'yı tercih etmesini nasıl sağlayabilirim?

Bazel, yalnızca IPv6 kullanan makinelerde bağımlılıkları herhangi bir değişiklik yapmadan indirebilir. Ancak Bazel, çift yığınlı IPv4/IPv6 makinelerde Java ile aynı kuralı uygular ve etkinse IPv4'ü tercih eder. Bazı durumlarda (ör. IPv4 ağı harici adresleri çözemediğinde/buralara ulaşamadığında) bu durum Network unreachable istisnalarına ve derleme hatalarına neden olabilir. Bu gibi durumlarda, java.net.preferIPv6Addresses=true sistem özelliğini kullanarak Bazel'in IPv6'yı tercih etme davranışını geçersiz kılabilirsiniz. Özellikle:

  • --host_jvm_args=-Djava.net.preferIPv6Addresses=true başlatma seçeneğini kullanın. Örneğin, .bazelrc dosyanıza aşağıdaki satırı ekleyerek:

    startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true

  • İnternete bağlanması gereken Java derleme hedeflerini (entegrasyon testleri gibi) çalıştırırken --jvmopt=-Djava.net.preferIPv6Addresses=true araç işaretini kullanın. Örneğin, .bazelrc dosyanıza şunları ekleyin:

    build --jvmopt=-Djava.net.preferIPv6Addresses

  • Bağımlılık sürümü çözümü için rules_jvm_external kullanıyorsanız Coursier için JVM seçenekleri sağlamak amacıyla COURSIER_OPTS ortam değişkenine -Djava.net.preferIPv6Addresses=true da ekleyin.

Depo kuralları, uzaktan yürütme ile uzaktan çalıştırılabilir mi?

Hayır, en azından henüz değil. Derlemelerini hızlandırmak için uzaktan yürütme hizmetleri kullanan kullanıcılar, depo kurallarının hâlâ yerel olarak çalıştığını fark edebilir. Örneğin, bir http_archive önce yerel makineye indirilir (varsa yerel indirme önbelleği kullanılır), ayıklanır ve ardından her kaynak dosya giriş dosyası olarak uzak yürütme hizmetine yüklenir. Uzaktan yürütme hizmetinin neden bu arşivi indirip ayıklayarak gereksiz bir gidip gelme işlemini atlamadığı sorusunu sormanız doğaldır.

Bunun bir nedeni, depo kurallarının (ve modül uzantılarının) Bazel tarafından çalıştırılan "komut dosyalarına" benzemesidir. Uzak bir yürütücünün Bazel yüklü olması gerekmez.

Diğer bir neden de Bazel'in, yerel olarak yapılan yükleme ve analiz işlemlerini gerçekleştirmek için genellikle indirilen ve ayıklanan arşivlerdeki BUILD dosyalarına ihtiyaç duymasıdır.

Depo kurallarını derleme kuralları olarak yeniden tasarlayarak bu sorunu çözmeye yönelik ön fikirler var. Bu fikirler, kuralların uzaktan çalıştırılmasına olanak tanır ancak yeni mimari endişeleri de doğurur (örneğin, query komutlarının işlemleri çalıştırması gerekebilir ve bu da tasarımlarını karmaşıklaştırır).

Bu konuyla ilgili daha önceki tartışmalar için Getirilmek için Bazel'e ihtiyaç duyan depoları desteklemenin bir yolu başlıklı makaleyi inceleyin.