rootstock, Copier tarzı proje şablonu güncellemelerini tek bir Rust binary'sine taşıyor

Copier'ın tek binary'lik yeniden uygulaması

Bir geliştirici, Python tabanlı proje şablonlama aracı Copier'ın Rust yeniden uygulaması olan rootstock'u yayınladı. dev.to'da yayınlanan bir yazıda, profesyonel olarak Rust yazan ve bodasooqa takma adını kullanan yazar, sürümlenmiş git şablonlarından projeler oluşturan ve bunları üç yönlü merge'ler sayesinde güncel tutan, tek bir binary olarak paketlenen ve tek runtime bağımlılığı git olan bir aracı tanıtıyor.\n Yazıya göre motivasyon, Biome, Ruff ve uv gibi araçların benimsenmesini sağlayan aynı kolaylık: binary'nin kendisi dışında kurulacak hiçbir şeyi olmayan, hızlı ve kendi kendine yeterli binary'ler. Buna karşılık Copier, bir şablona dokunan her makinede ve CI işinde Python ve pipx bulunmasını gerektiriyor.

Mevcut projeleri beslemeye devam eden şablonlar

Çoğu iskele aracı — yazıda cargo-generate, kickstart ve cookiecutter sayılıyor — bir şablonu bir kez render eder, sonrasında proje ve şablon yollarını ayırır. Bu tek seferlik kullanım için işe yarar ama şablon sürekli gelişirse çöker: paylaşılan CI workflow'ları, lint yapılandırmaları veya bir ekibin her yerde kullandığı bir servis iskeleti. Şablonda yapılan bir düzeltme, ondan üretilmiş projelere asla ulaşmaz.

Copier'ın çözümü, bir projenin nasıl oluşturulduğunu kaydetmek ve sonraki şablon değişikliklerini yerel düzenlemeleri koruyarak bunun üzerine yeniden oynatmaktır. rootstock aynı modeli uygular. new komutu bir şablonu render eder ve projenin yanına, şablon kaynağını, tag'i, tam commit'i, kullanıcının cevaplarını ve yazılan dosyaların listesini kaydeden bir .rootstock.toml dosyası yazar. İsim, anaç (rootstock) kendi yolunda büyüyen bir kalemi (scion) beslediği aşılama tekniğinden gelir: şablon, ondan ayrılan projeleri beslemeye devam eder.

git ile üç yönlü merge

Güncelleme sırasında rootstock şablonu geçici dizinlere iki kez render eder: kayıtlı cevaplarla eski sürümü (base) ve güncel cevaplarla yeni sürümü (target). Ardından base, target ve gerçek proje dosyasını dosya dosya karşılaştırır. Bir dosyayı yalnızca şablon değiştirdiyse şablonun sürümü alınır; yalnızca kullanıcı değiştirdiyse hiçbir şey olmaz; ikisi de değiştirdiyse dosya, Copier'ın kullandığı mekanizmayla git merge-file üzerinden geçer. Yazar, git CLI'nin bir merge kütüphanesi yerine bilinçli olarak seçildiğini, böylece sonuçların Copier ile eşleştiğini, conflict marker'ların tanıdık kaldığını ve kullanıcının yerel git yapılandırmasının merge'i etkileyemediğini söylüyor.

Merge edilemeyen durumlar açıkça ele alınıyor. Düzenlenmiş bir binary dosya kullanıcının kopyasını korur, şablonun sürümü yanına name.rootstock-new olarak yazılır. Kullanıcının sildiği ama şablonun değiştirdiği dosya silinmiş kalır ve raporlanır. Bir README gibi başlangıç içeriği olarak işaretlenmiş dosyalar bir kez yazılır ve bir daha dokunulmaz. Cevaplar oluşturulduktan sonra da değiştirilebilir: update --data ci=false, şablon sürümü ilerlememiş olsa bile yeniden render eder.

CI için tasarlanmış exit code'lar

İnsan müdahalesi gerektiren her durum exit code 2 ile biter ve her sorun için stdout'a bir satır yazılır, rutin çıktı ise stderr'e gider. Yazar bunu her projeye bağlı günlük bir iş akışında kullanıyor: rootstock update çalıştırılır, bir pull request açılır ve exit code conflict bildirdiğinde etiketlenir. Temiz minor ve patch güncellemeleri CI yeşil olduğunda kendiliğinden merge edilir; conflict'li olanlar inceleme bekler.

Yardımcı bir komut olan rootstock check, ağ erişimi olmadan CI'da çalışır ve artakalan conflict marker'larında ya da yan dosyalarda başarısız olur; böylece yarı çözülmüş bir güncelleme ana dala sızmaz. Güncellemenin tamamı sıradan bir git diff olarak gelir, böylece herhangi bir değişiklik kadar incelenebilir ve geri alınabilir olur.

Migration ve mevcut sınırlar

rootstock import-copier, mevcut bir Copier şablonunu, Copier'ın ürettiği bir projeyi ya da aynı dizini paylaşıyorlarsa ikisini dönüştürür ve dönüştürmenin tamamı başarılı olmadıkça hiçbir şey yazmaz. Yalnızca copier.yml içeren eski şablon sürümleri update tarafından doğrudan okunur ve bellekte dönüştürülür. Yazarın kabul testi, kendi şablonundaki her cevap kombinasyonu için Copier 9.19'a karşı bayt bayt aynı render edilmesi oldu — bu eşik o şablon için sağlandı, evrensel bir garanti değil.

0.1.0 sürümünde araç, yazarının kendi şablonlarının kullandığı Copier alt kümesini kapsıyor. Copier'ın _migrations'ı, Jinja extension'ları ve bazı soru türleri uygulanmamış; bir şablon bunları gerektiriyorsa importer, tam bir listeyle duruyor. Kurulum cargo install rootstock --locked ile ya da GitHub Releases'teki Linux (statik musl), macOS ve Windows için önceden derlenmiş binary'lerle yapılıyor.

Neden önemli

Şablon sapması, projeler arasında iskele paylaşan herhangi bir ekip için sessiz bir vergidir: düzeltmeler şablona düşer ama onlara ihtiyaç duyan koda asla ulaşmaz. Copier, şablonları tek seferlik üreticiler rather than uzun ömürlü bağımlılıklar olarak ele almanın sorunu çözdüğünü kanıtladı, ama Python runtime'ı, ona dokunan her makineye ve pipeline'a kurulum sürtünmesi ekliyor. rootstock bu modeli kendi kendine yeterli bir Rust binary'sine taşıyor ve ayrıca hata durumlarını otomasyonun çevresinde tasarlıyor: yapılandırılmış exit code'lar, çevrimdışı doğrulama ve incelenebilir diff'ler olarak gelen güncellemeler. Erken bir aşamada — kısmi Copier kapsamı ve uyumluluğun tek bir şablonda doğrulandığı 0.1.0 sürümü — ama temel fikir, üretilen projelerin şablon iyileştirmelerini almaya devam etmesi gerektiği, artık bir Python toolchain'i olmadan da mümkün.