Dockerize edilmiş Flask / Django uygulamalarında pip yerine Uv’ye geçmek

• uv’ye geçildiğinde Python bağımlılıklarını kurma hızı pip’e kıyasla yaklaşık 10 kat artıyor ve ayrı bir venv olmadan da root olmayan (non-root) kullanıcıyla çalıştırmak mümkün oluyor
• pyproject.toml tabanlı yapıda yalnızca üst düzey bağımlılıkları belirtmek yeterli; uv lock dosyasını otomatik olarak yönetiyor ve bağımlılık ağacı ile kesin sürüm yönetiminde pip freeze’den daha başarılı
• Dockerfile içinde uv ve uvx ikililerinin kopyalanması, pyproject.toml/uv.lock dosyalarının kullanılması, ortam değişkenlerinin ayarlanması gibi adım adım değişiklikler gerekiyor
• uv sync/add/remove, uv:outdated gibi komutlarla bağımlılık ekleme, kaldırma, güncelleme ve paketlerin en güncel sürümlerini kontrol etme gibi çeşitli yönetim işlemleri kolayca yapılabiliyor
• Lock dosyalarını düzenli yönetmek ve bağımlılık güncellemelerini sürdürmek mümkün hale geldiği için ekip çalışması ve dağıtım ortamlarında tutarlılık sağlama açısından avantaj sunuyor

---

10 kat daha hızlı bağımlılık kurulumu, venv kullanmadan, root olmayan ortam kurulumu

• uv, mevcut pip’e kıyasla Python projelerinde bağımlılık kurulum hızını büyük ölçüde iyileştiren bir araç
• uv kullanımıyla Flask/Django gibi çeşitli projelerde pip’e göre yaklaşık 10 kat daha hızlı kurulum deneyimi elde edilebiliyor
• Ayrı bir sanal ortam (venv) olmadan da konteyner içinde root olmayan kullanıcıyla güvenli şekilde çalıştırmak mümkün

pyproject.toml ve requirements.txt karşılaştırması

• Mevcut requirements.txt yerine yalnızca üst düzey bağımlılıkları pyproject.toml dosyasında belirtmek yeterli; uv otomatik olarak uv.lock dosyasını oluşturuyor
  • pyproject.toml içine [project] dependencies alanı ekleniyor
  • mevcut requirements.txt siliniyor
• uv’nin lock dosyası pip freeze çıktısına benzer, ancak daha doğru bir bağımlılık ağacı ve sürüm bilgisi içeriyor

Dockerfile yapısındaki değişiklikler

• Kullanmak için uv ve uvx ikilileri konteynere kopyalanıyor (statik derlenmiş Rust ikilileri kullanılıyor)
• Mevcut requirements*.txt yerine pyproject.toml, uv.lock* dosyaları kopyalanıyor
• Ortam değişkenleri ekleniyor:
  • UV_COMPILE_BYTECODE=1: bytecode’u build aşamasında önceden derler
  • UV_PROJECT_ENVIRONMENT="/home/python/.local": ayrı bir venv oluşturmadan paketleri belirli bir yola kurar
• Bağımlılık kurulum komutu da mevcut pip3-install yerine uv-install olarak değiştiriliyor
  • Örnek: RUN chmod 0755 bin/* && bin/uv-install

Bağımlılık ekleme, kaldırma, güncelleme ve diğer yönetimler

• Ayrı bir run betiğiyle konteyner içinde uv komutları çalıştırılabiliyor
  • ./run deps:install: image build edildikten sonra lock dosyasını host’a dışa aktararak kurulum yapar
  • ./run deps:install --no-build: build yapmadan yalnızca lock dosyasını günceller
  • ./run uv add mypackage --no-sync: yalnızca pyproject.toml ve lock dosyasını günceller, gerçek kurulum daha sonra yapılır
  • ./run uv remove mypackage --no-sync: paketi kaldırır
  • ./run uv:outdated: mevcut bağımlılıkların en güncel sürümlerini kontrol eder

Video ve uygulamalı rehber sunuluyor

• uv’ye geçiş, pyproject.toml yazımı, Dockerfile değişiklikleri, lock/sync komutları, bağımlılık ekleme/kaldırma ve güncel sürüm kontrolü gibi konular için gerçek demo ve git diff örnekleri sunuluyor
• Flask ve Django için iki projenin migration diff’lerine de bakılabiliyor

[yangeok]

Zaten Poetry ile dağıttığımız şeyi migrate etmeyi düşünüyordum; bu da stabil ve basit görünüyor ^^

[GN⁺]

Hacker News görüşü

• uv'nin pyenv, virtualenv ve pip'in doğrudan yerine geçen bir iş akışını desteklediğine dikkat etmek gerekiyor. Bu, lockfile ya da pyproject.toml ile dayatılan bir yaklaşım değil. uv python pin <version> komutuyla mevcut dizinde .python-version dosyası oluşturulabiliyor, uv virtualenv ile pyenv benzeri şekilde o sürüm Python indirilip .venv sanal ortamı yaratılabiliyor, uv pip install -r requirements.txt ile requirements.txt içindeki paketler kurulabiliyor, uv run <command> ile de .env dosyasındaki ortam değişkenleri dahil edilerek komut çalıştırılabiliyor. Yalnız, ortam değişkeni önceliği konusunda dikkatli olmak lazım (ilgili issue)

  • uv'nin esnekliği gerçekten hayranlık uyandıracak düzeyde. pip ile 10 dakika süren işi uv ile 20-30 saniyede halletme deneyimi
  • uv kullanmaya başlama sebebim tam olarak buydu. İnanılmaz kullanışlı. Yalnız bazen uv pip yavaş olabiliyor ve nedenini bilmiyorum; belki şirket ağ ortamıyla ilgilidir
  • Python sürüm bilgisinin pyproject.toml içinde de tutulduğunu sanıyordum; bu durumda .python-version dosyası gerçekten gerekli mi diye merak ediyorum

• # Her zaman güncel bir lock file olmasını garanti eden script
  if ! test -f uv.lock || ! uv lock --check 2>/dev/null; then
    uv lock
  fi
  

  Böyle bir yaklaşım lock file'ın varlık nedenini anlamsızlaştırıyor. Dosya yoksa ya da geçersizse, bu lock file'da ciddi bir sorun olduğu anlamına gelir ve projeye hakim birinin buna doğrudan müdahale etmesi daha doğru olur. Aksi halde lock file tutmanın anlamı kalmaz. CI'ın lock file'ı otomatik değiştirip kafa karışıklığı yaratması da mümkün

  • (yazarın yanıtı) Lock file geçersiz olduğunda sessizce geçilip yeni dosya oluşturulmuyor. uv lock anlaşılır bir mesajla hata veriyor ve shell script'teki errexit nedeniyle süreç anında duruyor. uv lock --check için hata çıktısının yönlendirilmesi, aynı hatanın iki kez basılmasını önlemek için. Lock dosyasını bilerek bozup script'i çalıştırırsanız, belirli hata mesajıyla birlikte build duruyor. Script'i daha açık olması için if-else yapısına çevirdim. Lock file yoksa yenisini oluşturmak zaten doğru akış. Bu noktada oluşturup commit etmek yeterli
  • Bu durum uv sync --locked seçeneğiyle kapsanıyor. Lock file yoksa ya da güncel değilse net biçimde hata veriyor. Build'lerin her zaman --locked ile çalıştırılmasını öneririm
  • Python dünyasında lock file'lar çoğu zaman sürüm kontrolüne eklenmiyor ve kurulum sürecindeki "garip bir adım" gibi ele alınıyor
  • Bu yaklaşımda ciddi bir bug var. --frozen bayrağı kullanıldığında lock file'ın güncellenmemesi gerekirken pratikte tam tersi çalışıyor. Lock file yoksa ya da eşleşmiyorsa insan müdahalesi gerektiği görüşüne katılıyorum
  • Yine de lock file yoksa bu ya ilk çalıştırmadır ya da zaten git upstream üzerinden üzerine yazılacaktır. Bozuksa birisi kurulumda hata yapmıştır ve yeniden oluşturmak fiilen tek mantıklı yol gibi görünüyor. Nadir bir istisna ama basit bir işlem için yeterince iyi

• Python araçlarının Python dışındaki bir dille geliştirilmesine tamamen karşıyım. C zaten var ve CPython standartlaşmış durumda; durduk yere yeni bir dile (ör. Rust) gerek yok. Pendulum paketinin 3.13 desteğini 7 aydan uzun geciktirmesinin sebebi de Rust native kısmını düzeltebilecek insan sayısının az olması diye düşünüyorum. C olsaydı kendim düzeltirdim. (ilgili issue) İdeal olarak, Rust gibi harici bir dille hızlı bir datetime yapmak istiyorsanız, onu FFI üzerinden birden çok dilde kullanılabilecek biçimde sunmanız gerekir. Rust tabanlı yaklaşım hâlâ içime sinmiyor ve Linux topluluğunun buna mesafeli durmasını da artık anlayabiliyorum

  • Bu bakış açısına saygı duyuyorum ama uv gibi araçların Rust ile yazılmasının iyi bir fikir olduğunu düşünüyorum. Python yönetim aracını Python ile yazınca "tavuk mu yumurtadan, yumurta mı tavuktan" durumu oluşuyor. Python aracını kullanmak için önce Python'un kurulu olması gerekiyor; hangi Python sürümünün kullanılacağı, aracın kullandığı kütüphanelerle gerçek uygulama arasındaki olası çakışmalar, ortam değişkeni yönetimi ve debug süreçleri de karmaşıklaşıyor. Buna karşılık Rust vb. ile derlenmiş ikili araçları indirip doğrudan kullanabiliyorsunuz; bunların hiçbiriyle uğraşmadan anında çalışıyor. Kullanıcının da aracın hangi dille yazıldığıyla çok ilgilenmesine gerek yok
  • Python'u seviyorum ama uv'nin sadeliği ve hızıyla kıyas kabul etmez. EOL olmuş sunucularda yeni Python gerektiğinde ya da küçük bir script için yalnızca bağımlılıkları hızla kurmak istediğinizde uv en iyi seçenek. Katıldığım noktalar da var; eskiden her şeyi pure Python yazardım, sonra C extension kullanmaya başladım, sınırına gelince neredeyse her şeyi C ile yazmak ister oldum. C zor olduğu için son dönemde Rust'a refactor ediyorum. Dış kod iç koddan fazla olmaya başladığında, her şeyi başka bir dile taşımak daha mantıklı oluyor
  • Araçların yalnızca Python ile yazılması gerektiğini düşünüyorsanız, yavaş Pylint'i beklerken ben yürüyüşe çıkmış olurum
  • Birden çok dil desteği kullanıcı için ciddi bir yük değil. Araç hızlıysa ve sorunu iyi çözüyorsa yeter. Gerçekten çok daha hızlı. Yönetim araçları, kullanıcılar için değil geliştiriciler için araçlardır
  • Ben hangi dille yazıldığına bakmam; işini iyi yapıyorsa yeter. Python kullanıcılarının araca katkı verebilmesi bir artı ama araç amacını yerine getiriyorsa dilin önemi yok. Hatta ortam sorunlarına çarptığınızda, Python ile yazılmış bir araç o sorunlardan kendisi de etkilenebilir

• pip yerine uv kullanırken dikkatli olmak lazım. Varsayılan olarak pyc dosyaları üretmiyor, bu da servis başlangıcını yavaşlatabilir (referans)

  • Konteyner içinde uv kullanıyorsanız rehber doküman daha faydalı oluyor (Docker rehberi)

• Flask konteynerinde uv kullanınca sadece build süresi can sıkıcı ölçüde kısalmıyor, kurulum süreci de çok daha öngörülebilir hale geliyor. pip ile bağımlılık sürümlerinin değişmesinden doğan şaşkınlık yaşanmıyor. pyproject.toml kullanıp uv lock demeniz yeterli. Docker'da yalnızca pyproject.toml ve uv.lock dosyalarını kopyalayıp (HOT COPY) uv sync --frozen --no-install-project çalıştırırsanız, uygulama kodunu atlayarak kurulum katmanını cache'lemek mümkün. Tek bir paketin değişmesi yüzünden tüm katmanı yeniden build etmenin acısını bilen biri için bunun neden önemli olduğu açık. UV_PROJECT_ENVIRONMENT=/home/python/.local ortam değişkeniyle venv kullanmadan base image'ı pre-warm etmek, build paylaşımı ve altyapı maliyetlerinde tasarruf sağlayabiliyor. UV_COMPILE_BYTECODE=1 seçeneğiyle build sırasında .pyc dosyaları da oluşturuluyor. Mutable environment ortadan kalkıyor ve reproducibility zorunlu hale geliyor; artık build başarısız olursa sebebin lockfile olduğu netleşiyor

• 2025 olmuşken bile Python paketleme ve bağımlılık yönetimi hâlâ karmaşık durumda

  • Bence bunun nedeni herkesin uv kullanmıyor olması; o yüzden karmaşa sürüyor
  • Bu, dil tasarımının ilk aşamasında bu tür konuları doğru kurgulamanın önemli olduğuna dair bir ders. v2.0 sonrasına ertelemeyin, metadata'yı çalıştırılabilir script'lerin içine koymadan önce defalarca düşünün; bazı dillere uyan yaklaşım Python için iyi olmayabilir
  • Ben bağımlılık sorunlarıyla hiç karşılaşmadım. requirements.txt ve venv bana yetiyor
  • Bağımlılık yönetimi hâlâ darmadağın; şimdi bir de Rust eklendi

• uv, pip, conda gibi Python paket yöneticilerinin güvenliğini karşılaştırmayı merak ediyorum. Hız güzel ama paket yöneticisinin güvenliği bence çok daha önemli

  • uv, pip'e göre daha güvenli tarafta. Bağımlılıkları rastgele kod çalıştırmadan analiz ediyor, varsayılan olarak paket hash'lerini doğruluyor, typosquatting gibi çeşitli riskleri azaltıyor. Hız ve yeniden üretilebilirlik açısından da güçlü (teknik yazı, uyumluluk dokümanı)
  • Ama özünde tüm paket yöneticileri doğrulanmamış üçüncü taraf kodu indirip çalıştırıyor. uv ile pip arasındaki uygulama düzeyi güvenlik farkından çok, baştan harici koda ilişkin bir politika oluşturmamış olmak daha büyük risk etkeni

• PyPI'ye paket yükleyen biri olarak, şahsen hızından dolayı uv kullanmak isterim ama pip ile tamamen aynı şekilde çalıştığı garanti edilmiyorsa kolay kolay geçemem. Sonuçta bir kullanıcı pip install xxx ile hata alırsa, benim de aynı ortamı yeniden kurup sorunu debug edebilmem gerekir

  • pip ile %100 aynı davranmıyor. Başlıca farklar uyumluluk dokümanında anlatılıyor. Bunların bir kısmı standartlara doğru geçişten, bir kısmı ise uv'ye özgü tasarım tercihlerinden kaynaklanıyor

• UV'nin, sadece çalıştırdığınızda bile iyi sonuç veren ve son dönemde Python paketleme dünyasındaki en olumlu değişimlerden biri olduğunu düşünüyorum

• Üretim ortamı konteynerleri kurarken uv kullanımına dair çok iyi bir rehber de paylaşılmış (rehbere bakın)