PYTHON PACKAGING VENV VE POETRY

Veri Akademi•8 dk okuma

Python paketleme akışı venv izole ortam pyproject toml manifest ve poetry lock dosyası

JetBrains 2024 Python Developer Survey'e göre geliştiricilerin yaklaşık %85'i hâlâ pip kullanıyor; ancak poetry payı %37'ye, hızla yayılan uv ise birkaç ay içinde %11'e ulaştı. Bu rakamlar, Python ekosisteminin tek bir paket yöneticisinde karar kılmadığını ve doğru aracı seçmenin proje ömrü boyunca tekrar tekrar gündeme geldiğini gösteriyor. Aşağıda beş aracın ne işe yaradığını, hangi sorunu çözdüğünü ve hangi durumda hangisinin tercih edilmesi gerektiğini somut özellik tablolarıyla aktarıyoruz.

1. Python'da Paketleme Sorunu Nereden Çıkıyor?

Python kurulumu sistem üzerinde tek bir global site-packages dizinine sahiptir. Aynı makinede iki farklı proje, Django 3 ve Django 5 gibi uyumsuz sürümleri talep ettiğinde çakışma kaçınılmazdır. Paketleme araçlarının var olma nedeni budur: izole ortam, deterministik bağımlılık çözümü ve yayınlanabilir bir artefakt. Daha fazla bilgi için geniş kapsamlı belgeleri başvurulabilir.

Bir paket yöneticisinden beklenenler genellikle şu başlıklar altında toplanır:

Sanal ortam oluşturma ve yönetme
Bağımlılıkları çözme (resolver) ve kilitleme (lock file)
Geliştirme ve üretim bağımlılıklarını ayırma
Paketi PyPI'ye yayınlama (build + publish)
Python sürümünü kendisi kurabilme

Tek bir araç bu beş işi de eşit ağırlıkta yapmaz. Kullanım payları ve hedef kitleler farklılaşır.

2. Kullanım Payları: 2024 Verileri ile Manzara

Python paket yöneticilerinin pazar payı pip poetry uv pipenv conda yatay karşılaştırma grafiği

JetBrains ve Python Software Foundation ortak anketi, hangi aracın hangi paya sahip olduğunu net biçimde ortaya koyuyor:

pip: ~%85 (Python ile birlikte gelen varsayılan kurucu)
conda / mamba: ~%29 (veri bilimi ve bilimsel hesaplama ağırlıklı)
poetry: ~%37 (modern uygulama ve kütüphane geliştirme)
pipenv: ~%10 (eski projelerde devam ediyor, yeni kurulumlarda gerileme)
uv: ~%11 (Astral tarafından 2024 başında duyuruldu, hızla büyüyor)
hatch, pdm, rye: toplam %5-8 bandında

Toplam %100'ü geçmesinin nedeni geliştiricilerin birden fazla aracı paralel kullanmasıdır; örneğin bir ekibin poetry ile bağımlılık tanımlayıp CI'da pip ile kurulum yapması olağandır.

3. pip ve virtualenv: Temel Katman

pip, Python'ın resmi paket kurucusudur ve Python 3.4'ten itibaren standart kütüphane ile birlikte gelir. virtualenv ise pip'ten önce sanal ortam ihtiyacını karşılamak için doğmuştur; bugün büyük ölçüde standart kütüphanedeki venv modülü aynı işi görür.

Tipik akış şu şekildedir:

python -m venv .venv ile izole ortam
.venvScriptsactivate (Windows) veya source .venv/bin/activate (POSIX)
pip install -r requirements.txt ile bağımlılıkları kurma
pip freeze > requirements.txt ile sürümleri dondurma

Bu kombinasyonun zayıf yanı, requirements.txt'nin gerçek bir lock dosyası olmamasıdır. Geçişli bağımlılıkların sürümleri makineye göre değişebilir. Ayrıca paket yayınlama, geliştirme/üretim ayrımı veya Python sürümü yönetimi pip'in kapsamı dışındadır.

4. pipenv: requirements.txt'den Lock'a Geçiş

pipenv 2017'de PyPA tarafından önerilen bir araç olarak çıktı. Pipfile ve Pipfile.lock ile deterministik kurulum vaadi getirdi. Ancak bağımlılık çözüm hızı uzun süre tartışma konusu oldu ve sürüm yayınları kesintili ilerledi. Bu nedenle yeni projelerde tercih oranı düşmektedir. Mevcut pipenv kullanan projelerin korunması mantıklıdır; sıfırdan başlayan ekipler genelde poetry veya uv tarafına yönelir.

5. poetry: Modern Uygulama Geliştirme

poetry, pyproject.toml üzerinden hem bağımlılıkları hem paket meta verisini tek dosyada tutar. poetry.lock tüm geçişli sürümleri kilitler. Yayınlama (poetry publish) ve build işlemleri tek komutla yapılabilir.

Özellik tablosu açısından poetry'nin güçlü yönleri:

SAT-tabanlı bağımlılık çözücü (çakışmaları net raporlar)
Geliştirme bağımlılığı için --group dev
Kütüphane ve uygulama modunu ayırma
Plugin sistemi

Zayıf yönü tarihsel olarak çözüm hızıydı; büyük projelerde lock dosyası üretimi dakikalar sürebiliyordu. Sürüm 1.5'ten sonra bu önemli ölçüde iyileşti.

6. uv: Rust ile Yazılmış Yeni Nesil

uv paket yöneticisi Rust tabanlı hızlı bağımlılık çözümü ile pip ve poetry kıyaslaması

uv, ruff'ı geliştiren Astral ekibi tarafından Şubat 2024'te duyuruldu. Rust ile yazılmıştır ve pip ile aynı arayüzü taklit ederek başladı, sonrasında poetry benzeri proje yönetimine doğru genişledi. Ölçümlerde pip'ten 10-100x, poetry'den ise lock üretiminde belirgin biçimde daha hızlı sonuç verir.

uv'nin diğer araçlardan ayrıştığı noktalar:

Python yorumcusunu kendisi indirip yönetebilmesi (pyenv'e ihtiyacı azaltır)
Tek bir çalıştırılabilir dosya (Python kurulumu olmadan da çalışır)
pip-compile / pip-sync uyumlu komut seti
Workspace ve monorepo desteği

Olgunluk anlamında hâlâ genç bir araçtır; ancak benimseme hızı yüksektir.

7. Karşılaştırma Tablosu: Hangi Araç Neyi Yapar?

Beş aracın temel özellikleri yan yana getirildiğinde şu tablo ortaya çıkar:

Sanal ortam yönetimi: pip yok / virtualenv var / pipenv var / poetry var / uv var
Lock dosyası: pip yok / virtualenv yok / pipenv var / poetry var / uv var
Paket yayınlama (build & publish): pip kısmi / virtualenv yok / pipenv yok / poetry var / uv var
Python sürümü kurma: sadece uv (yerleşik)
Çözüm hızı: uv > poetry > pipenv > pip
Olgunluk: pip > virtualenv > pipenv > poetry > uv

Bu tabloyu kendi projenize uygulamak için Python ekosistemine dair temel kavramları gözden geçirmek isterseniz Python eğitim içeriğinden yararlanabilirsiniz.

8. Hangi Senaryoda Hangi Araç?

Seçim, projenin türüne ve ekibin alışkanlığına göre değişir:

Tek dosyalık script veya öğrenme aşaması: pip + venv yeterli
PyPI'ye yayınlanacak kütüphane: poetry veya hatch
Hız kritik CI/CD pipeline'ı: uv
Veri bilimi, derin öğrenme, native bağımlılık ağırlıklı iş: conda / mamba
Mevcut pipenv projesi: migrasyon zorunlu değilse devam, yeni proje açılıyorsa poetry veya uv

Çoğu ekip için pratik öneri şudur: Bağımlılıkları pyproject.toml'da tanımlayın, lock dosyası kullanın, CI'da kurulumu uv ile hızlandırın. Bu kombinasyon, hem standartlara hem hıza uyar.

9. Geçiş ve Birlikte Yaşama

Bir araçtan diğerine geçiş genellikle pyproject.toml üzerinden yapılır. poetry export ile requirements.txt üretip pip veya uv'ye aktarmak mümkündür. uv, poetry'nin lock formatını henüz okumaz; ancak pyproject.toml'daki bağımlılık tanımını okuyup kendi lock'unu üretebilir. pipenv'den çıkarken Pipfile'ı manuel olarak pyproject.toml'a çevirmek pratik bir yoldur.

Araçların hızla evrildiği bu dönemde tek bir araca koşulsuz bağlanmak yerine, pyproject.toml standardına yatırım yapmak en sağlam yaklaşım gibi görünüyor. Python paketlemesi konusunda derinleşmek isteyenler yapılandırılmış Python eğitimi ile konunun temellerini takip edebilir.

pyproject toml standart dosyası ve poetry uv pdm hatch araçları ortak okuma akışı

Sonuç olarak pip varsayılan olarak kalmaya devam edecek; poetry kütüphane geliştirmede konumunu korurken uv, hızıyla CI ve uygulama tarafında hızlı pay kazanıyor. Pipenv ve virtualenv ise giderek arka plana çekiliyor. Karar verirken aracın özellik tablosundan çok, ekibin günlük iş akışıyla nasıl örtüştüğünü ölçmek daha sağlıklı bir kriterdir.

Sıkça Sorulan Sorular

pip varken neden poetry veya uv gibi araçlara ihtiyaç var?

pip yalnızca paket kurar; sanal ortam yönetmez, lock dosyası üretmez, paket yayınlamaz ve Python sürümü kurmaz. Poetry ve uv bu beş işi tek arayüzde birleştirerek geliştirici deneyimini sadeleştirir. Özellikle takım çalışmasında deterministik kurulum için lock dosyası kritik bir gerekliliktir.

requirements.txt ile poetry.lock arasındaki temel fark nedir?

requirements.txt genellikle <code>pip freeze</code> çıktısıdır ve geçişli bağımlılıkların hash'lerini, kaynak işaretçilerini veya çözüm grafiğini içermez. poetry.lock ise tüm geçişli sürümleri, hash değerlerini ve hangi paketin hangi grupta olduğunu kayıt altına alır; bu sayede farklı makinelerde birebir aynı kurulum garanti edilir.

uv, poetry'nin yerini tamamen alacak mı?

Şu an için hayır. uv hızıyla pip ve pip-tools alanını yiyor; poetry ise paket yayınlama, plugin ekosistemi ve uzun süredir kullanılan komut seti açısından olgun. Pek çok ekip ikisini birlikte kullanıyor: poetry geliştirme tarafında, uv CI'da kurulum hızlandırıcı olarak.

Veri bilimi projelerinde neden hâlâ conda tercih ediliyor?

conda yalnızca Python paketlerini değil, native C/C++ kütüphanelerini, CUDA sürümlerini ve sistem düzeyi bağımlılıkları da yönetir. NumPy, SciPy, PyTorch gibi paketlerin GPU veya MKL destekli sürümlerini kurmak conda ile genellikle daha az sürtünmelidir. pip + uv ile de mümkün ancak daha çok manuel ayar gerektirir.

pipenv hâlâ aktif bir proje mi?

Evet, pipenv sürüm yayınlamaya devam ediyor; ancak yeni proje başlatımlarındaki payı belirgin biçimde düşmüş durumda. Mevcut pipenv kullanan projeler için zorunlu bir migrasyon yoktur. Yeni bir projeye sıfırdan başlanıyorsa poetry veya uv genellikle daha öne çıkan tercihlerdir.

pyproject.toml standardı neden bu kadar önemli?

PEP 518 ve PEP 621 ile tanımlanan pyproject.toml, paket meta verisini ve bağımlılıkları araç-bağımsız biçimde tanımlar. poetry, hatch, uv ve pdm gibi araçlar bu dosyayı okuyabilir. Böylece bir araçtan diğerine geçiş çoğu zaman tek dosya üzerinden yapılır; setup.py veya Pipfile gibi araca özgü formatlara mahkum kalınmaz.

uv'nin Python sürümünü kendisi kurabilmesi pratikte ne işe yarıyor?

Daha önce farklı Python sürümleriyle çalışmak için pyenv, asdf veya conda gibi ek araçlar gerekiyordu. uv, ihtiyaç duyulan sürümü kendisi indirip projeye bağlar. Bu hem CI imajlarını sadeleştirir hem de yeni başlayan birinin tek komutla doğru Python sürümünde projeye girmesini sağlar.

Küçük bir script için bile poetry veya uv kurmak gerekli mi?

Hayır. Tek dosyalık bir script veya öğrenme amaçlı bir çalışmada <code>python -m venv .venv</code> ve <code>pip install</code> yeterlidir. Lock dosyası, yayınlama veya çoklu ortam ihtiyacı doğmadığında ek bir aracı projeye dahil etmek gereksiz yük oluşturur.