uv ve PEP 723 ile Python betiklerinden yararlanmak

 (cottongeeks.com)
14 puan yazan GN⁺ 2025-06-25 | 2 yorum | WhatsApp'ta paylaş
  • uv paket yöneticisi ve PEP 723 sayesinde bağımlılık sorunları olmadan Python betikleri çalıştırmak mümkün hale geliyor
  • uvx özelliği, geçici sanal ortamları otomatik oluşturarak ortam kurulumundaki zahmeti ortadan kaldırıyor
  • PEP 723 meta verisi Python dosyasına eklendiğinde betiğin otomatik çalıştırılması ve paket yönetimi çok daha pratik hale geliyor
  • Çalışan betik örneği olarak bir YouTube altyazı çıkarma programı hızla geliştirilebilir ve dağıtılabilir
  • Böylece artık Python ile de kısa ve tek başına çalıştırılabilen dosyalar yazmak mümkün oluyor; bu da betiklerin kullanım alanını büyük ölçüde genişletiyor

Genel bakış

  • Python'da "tek seferlik (one-off) betikler" çalıştırırken her defasında ortam kurma ve paket yükleme zorunluluğu vardı; uv ve PEP 723 ile bu zahmet ortadan kalkıyor
  • uv, Rust ile geliştirilmiş yüksek hızlı bir Python paket ve proje yöneticisi; yeni uvx özelliğiyle birlikte geçici sanal ortam oluşturma, paketleri otomatik kurma ve Python sürümüyle eşleştirmeyi son derece hızlı ve kolay biçimde yapıyor

uv ve uvx'in avantajları

  • uvx özelliği, Nodejs ekosistemindeki npx'e benzer şekilde çalışarak belirtilen Python paketini (ör. ruff) çalıştırmak için hızlıca bir ortam oluşturuyor
  • Geçici sanal ortamı önbellek olarak kullanarak ek yük olmadan hızlı çalıştırma sağlıyor
  • Ortam kurulumu ve bağımlılık yükleme tek bir komut satırıyla yapıldığından, geliştiricinin ayrıca ortam yapılandırmasını yönetmesine gerek kalmıyor

PEP 723'e giriş ve kullanım

  • PEP 723, Python betiğinin en üst kısmına bağımlılık ve ortam meta verisi eklenebilmesi için bir standart tanımlıyor
  • Örnek: kodun üst bölümünde requires-python, dependencies gibi alanlar belirtilebiliyor
  • Bu bilgiyi tanıyan harici araçlar (ör. uv), betik dosyasındaki veriye bakarak otomatik kurulum, ortam hazırlığı ve çalıştırmayı gerçekleştiriyor

uv ve PEP 723'ün birleşimi

  • Gerçek bir Python örnek dosyasının üst kısmına bu meta veri yazıldığında, uv'nin run komutuyla çalıştırma sırasında gerekli tüm paketler otomatik kuruluyor, belirtilen Python sürümü ayarlanıyor ve ardından kod yürütülüyor
  • Örnek kod internet üzerindeki bir API'yi (PEP listesi) çağırıp sonucu ekrana yazdırıyor. Ek paket kurulumu ya da ortam ayarı olmadan tek satırla çalıştırılabiliyor

Pratik örnek: YouTube altyazı betiği

  • shebang (#!/usr/bin/env -S uv run --script) ve PEP 723 meta verisi eklenmiş bir Python betiği örneği sunuluyor
  • youtube-transcript-api gibi harici paketler otomatik kuruluyor ve sanal ortam da otomatik hazırlanıyor
  • Kullanıcı, çalıştırılabilir dosyaya (ytt) YouTube video URL'sini ya da ID'sini argüman olarak verdiğinde, betik altyazıları çıkarıp sonucu anında sunuyor
  • chmod ile çalıştırma izni verildikten sonra terminalden kolayca kullanılabiliyor

Geliştirici deneyiminin iyileşmesi ve olasılıkların genişlemesi

  • Geçmişte basit betikleri çalıştırmak için Go gibi tek yürütülebilir dosya üreten diller daha çok tercih ediliyordu; artık Python da benzer düzeyde kolaylık sunuyor
  • uv ve PEP 723 kombinasyonu sayesinde Python betiklerini paylaşmak, dağıtmak ve otomatik çalıştırmak çok daha kolay hale geliyor
  • Github örneği (cottongeeks/ytt-mcp) üzerinden daha karmaşık kullanım senaryoları da geliştirilebiliyor

İlgili okumalar

2 yorum

 
ndrgrd 2025-06-25

uv çok hızlı olduğu için gerçekten hoşuma gidiyor. Bu aralar mümkün olan her yerde uv kullanıyorum.
 
GN⁺ 2025-06-25
Hacker News görüşleri

  • Yazının yazarı gibi ben de bugünlerde Go yerine çapraz platform Python one-off işleri ve kişisel script’lere daha çok yöneliyorum, ama Python’ın type checking sistemi tam bir kaos olduğu için memnun değilim; ty, pyrefly gibi araçların bunu biraz olsun iyileştirmesini umuyorum

  • Artık Python script’leri virtualenv yüzünden uğraştırmadan doğrudan düzgün çalışıyormuş gibi hissettiriyor Shell script tarafında da böyle bir deneyim olsa keşke diye düşünüyorum Paketleme, bağımlılık yönetimi ve yeniden üretilebilirlik hâlâ taş devri seviyesinde Şu an gerçeklik ya curl | bash ile şansa güvenmek ya da içinde 3 eksik bağımlılık ve 12 manuel adım olan bir README dosyasından ibaret Nix? Ancak zamanı, mekânı ve Nix kılavuzunu aşmış insanlar için işe yarar bir seçenek gibi Docker? Sırf bir kez sed komutu kullanmak için bir Linux dağıtımı indirmek sana mantıklı geliyorsa fena seçenek değil Herkesin kolayca kullanabileceği, basit ve deklaratif bir orta noktaya gerçekten ihtiyaç var diye düşünüyorum

    • Ben yalnızca hedef işletim sisteminde varsayılan olarak bulunan binary ve kütüphaneleri kullanan shell script’ler yazmayı tercih ediyorum Shell script’i taşınabilir yapmak hedefi pratikte pek uyumlu bir seçim değil macOS’a özel komutlar kullanan bir shell script’i Linux’ta çalıştırman gerekiyorsa, bunu hiçbir paket yöneticisi çözemaz
    • Nix bu amaç için aslında o kadar da zor bir kullanım deneyimi sunmuyor gibi Başka bir dağıtıma Nix kurup aşağıdaki gibi oldukça basit şekilde kullanılabileceğine dair bir örnek paylaşıldı NixOS ya da genel olarak Nix paketleme epey zorlayıcı olsa da, konu yalnızca shell script ise giriş eşiği nispeten düşük
    • Yeni shell script yazmaya pek ihtiyaç duymuyorum Tüm bağımlılıkların kurulmasına izin verilen bir ortamdaysan uv gibi araçlar her şeyi hallediyor Clojure seviyorsan babashka da tavsiye ederim
    • Shell script’lerde paketleme, bağımlılık yönetimi ve yeniden üretilebilirliğin ilkel görünmesinin nedeni, bunlara ihtiyaç duyulan noktada shell’in zaten uygun bir araç olmaması olabilir diye düşünüyorum Shell ancak 20 satır civarındaki küçük script’ler için uygun Dilin kendisi bundan daha büyük ölçekler için yeterince kaliteli değil
    • mise öneririm İş yerinde geliştirme ortamlarını yönetmek için kullanıyoruz ve Docker ile Nix’e göre ortam kurulumunu çok daha basit hâle getiriyor Paralel kurulum desteği de sıradan bir Dockerfile’a göre büyük avantaj sağlıyor

  • Gerçekten harika bir trend ve giderek daha yaygınlaştığını hissediyorum Bunu ilk kez simonw’nin blogunda görmüştüm; ilgili içerik için simonwillison’un blog yazısına bakılabilir Bu yıl mart ayında başka bir blog yazısı üzerinden Hacker News tartışması da olmuştu Bu trendin ana sayfada uzun süre kalıp daha fazla kişinin dikkatini çekmesini isterim

  • uv’yi küçük projelerde denedim, deneyim gerçekten çok iyi uv run ve uv tool run (uvx) kombinasyonuyla GitHub’daki Python script’lerini bir VM üzerinde doğrudan kurup çalıştırmak aşırı kolay git clone yok, venv oluşturma ya da içine girme yok, pip install da yok En önemlisi uv o kadar hızlı ki ilk başta bir şeylerin yanlış gittiğini düşündürüyor; gerçekte pip’ten 10 kat hızlı sonuç veriyor Yine de araç ve dokümantasyon biraz ham, ama yenilik ve pratiklik seviyesi bunu fazlasıyla telafi ediyor

    • uv’nin bağımlılıkları kurmasının, pyenv’in --help çıktısını göstermesinden daha hızlı olmasına içtenlikle hayran kaldım

  • Rust da benzer şekilde tek dosyalık, type’lı shell script fikrini geliştiriyor Bu yaklaşımı ilk kez Rust tarafında görmüştüm; tek dosya çalıştırma ve bağımlılık yönetimini birlikte destekliyordu Bu kalıbın daha fazla dilde yerleşmesini isterim; gist olarak paylaşmak ya da hızlı küçük araçlar yazmak için çok kullanışlı cargo-script RFC belgesine de bakılabilir

  • uv run --script kullanırken metadata’yı script’in içine koyarsan, script’ten doğrudan Python REPL açıp değişiklikleri denemek biraz kullanışsız oluyor Mesela aşağıdaki gibi yapmak gerekiyor,

    $ uv run --python=3.13 --with-requirements <(uv export --script script.py) -- python
>>> from script import X

    Daha kısa bir yol olsa iyi olurdu Örneğin,

    $ uv run --with-script script.py python

    gibi bir şey ideal olurdu, ama pratikte aşağıdakini çalıştırınca script’e uygun Python ve venv ortamına doğrudan girilebiliyor

    $ "$(uv python find --script script.py)"
>>> from script import X

    Yalnız bunun için ortamın oluşturulması adına script’i bir kez çalıştırmış olmak gerekiyor

    • Kurulumdan sonra REPL çağırma özelliğine ihtiyacın varsa şu gist örneğine bakabilirsin Script’e --interactive gibi bir flag ekleyip bunu CLI seçeneği hâline getirebilirsin Genelde Typer tabanlı küçük CLI’leri bu şekilde yazıyorum Geliştirme script’lerinde --sql flag’i ile DuckDB SQL REPL açtığım da oldu
    • Basit bir yöntem olarak şunu paylaşayım 
      cat ~/.local/bin/uve
#!/bin/bash
temp=$(mktemp)
uv export --script $1 --no-hashes > $temp
uv run --with-requirements $temp vim $1
unlink $temp

  • conda kullanıyorsan, Python script’i için shell wrapper içinde ortamı doğrudan aktive edebilirsin Şöyle yazılabilir:

    #!/usr/bin/env bash
eval "$(conda shell.bash hook)"
conda activate myenv
python myscript

    Yine de bu yaklaşım PEP 723 tarzı kadar bağımsız değil

  • Dünkü ve bugünkü HN başlıklarını görünce ilk kez uv denemeye karar verdim; hızı ve bağımlılık yönetiminin kolaylığı beni çok etkiledi Resmi dokümantasyon daha iyi olsa harika olurdu; özellikle requirements.txt iş akışından uv’ye geçiş kılavuzu çok faydalı olur gibi Proje bazında Python sürümü belirleme kısmı biraz kafa karıştırıyor (.python-version ve pyproject.toml içinde iki farklı yerde tanımlanması)

    • Python geliştirici araçları hakkında bir e-kitap yazmışlığım var Resmi dokümantasyonun eksik kaldığı yerleri anlatmıştım; requirements.txt’den geçiş yöntemi ve bir uv projesinin Python sürümü nasıl değiştirilir bağlantılarına bakabilirsin Ele alınmasını istediğin başka konular varsa her zaman önerebilirsin
    • pyproject.toml içindeki requires-version alanı, uyumluluğun garanti edildiği sürüm aralığını ifade eder; .python-version ise geliştirmede kullanılacak belirli sürümü belirtir uv init ile oluşturulduklarında başlangıçta aynı görünebilirler, ama zamanla requires-version, .python-version değerinden daha düşük bir minimum destek sürümünü gösterebilir requires-version paket metadata’sına da girer ve yayımladığın paketi kullanacak başkalarının bağımlılık çözümlemesini de etkiler Örneğin v1 eski Python 3 sürümlerini desteklerken v2 artık desteklemeyebilir
    • Ben de benzer hissediyorum; kendi iş akışımı bırakmıyorum (aynı dosyayı Dropbox ile tüm bilgisayarlar arasında senkronize edip platformdan bağımsız kullanmak gibi) Platform değişince npm ya da dotnet tarafında npm update veya dotnet restore gerekse de, venv sorunsuz çalışıyor Buna karşılık uv, platform değişimlerinde işleri daha karmaşık ve elle temizlik gerektirir gibi hissettiriyor
    • pyproject.toml, (uv ile doğrudan ilgili olmaktan bağımsız olarak) kodunu dış geliştiriciler ve kullanıcılarla paylaşırken gereken ortamı tanımlamak içindir PyPI için paket derlerken hangi ortamın gerektiğini belirtir ve sürüm aralıkları da daha çok kişinin kodu yeniden kullanabilmesi için belirlenir .python-version ise yalnızca uv’ye, yani benim geliştirme ortamımı kurarken başvurulan bilgiye yöneliktir Hazır bir ortamın zaten varsa bunu ayrıca ayarlaman şart değil uv henüz resmi bir build backend değil ama bunun üzerinde çalışıyor (issue #3957)
    • Çok derin bakmadım ama .python-version dosyasının rolü, TOML parser’ı olmayan diğer araçlarla uyumluluk sağlamak olabilir diye tahmin ediyorum

  • Eskiden Python script’lerinin bağımlılıkları kendi kendine kurmasını sağlayan bir araç yapmayı istemiştim (Hedef, uvx gibi çalışan ama yalnızca Python kurulu olsa bile işleyen bir araçtı) Ama script’in en üstüne biraz tuhaf görünen birkaç satır eklemek gerekmesi bir dezavantajdı Merak edenler için PyPI’da pysolate adıyla yayımlanmış durumda

    • Benzer ama çok yaygınlaşmamış bir isolate projesi de var Yaklaşımı biraz farklı ama ilginç bir örnek

  • COBOL’dan ilham alan Grace Hopper tarzı bir mesaj Her Python programının derleme ve çalışma ortamını, donanım ve yazılım gereksinimleri dâhil, açıkça belirten bir ENVIRONMENT division tanımlaması gerektiğini savunuyor Böyle bir yapı, programların farklı sistemler arasında taşınabilirliğini artırmada belirleyici olur