- Otomasyon betiklerini
~/bin/ içine koyup çalıştırma akışında uv ve satır içi betik meta verileri kullanıldığında Python betiklerini daha hafif şekilde yönetmek mümkündür
~/bin PATH içinde yer alıyorsa shebang satırını #!/usr/bin/env -S uv run --script olarak ayarlayarak dosya adını bir komut gibi çalıştırabilirsiniz- Bu yapılandırma, kabuğun önce
uv run --script komutunu çalıştırmasını ve mevcut betik dosyasını argüman olarak iletmesini sağlar
- uv, shebang satırını yok saydıktan sonra kalan içeriği normal bir Python dosyası gibi çalıştırır
chmod a+x {filname} ile çalıştırma izni verirseniz bunu bağımlılıkları otomatik yöneten basit bir Python komut satırı betiği olarak kullanabilirsiniz
uv’yi shebang olarak çalıştırma
- İş otomasyonu için
~/bin/ dizininde birden fazla betik oluşturup kullanıyorum
~/bin PATH içinde yer alıyorsa betikleri yalnızca dosya adıyla doğrudan çalıştırabilirsiniz- Bu durumda kullanılacak shebang şu şekildedir
#!/usr/bin/env -S uv run --script
Çalışma akışı ve izin ayarı
- Yukarıdaki shebang, komut satırında
uv run --script komutunu çalıştırır ve betik dosyasını argüman olarak iletir
- uv, shebang satırını yok saydıktan sonra dosyanın kalan kısmını normal Python kodu olarak çalıştırır
- Çalıştırmadan önce betiğe çalıştırma izni verilmelidir
chmod a+x {filname}
- Kurulum tamamlandığında bağımlılıkları otomatik olarak yöneten basit bir Python komut satırı betiğini doğrudan çalıştırabilirsiniz
1 yorum
Hacker News yorumları
Bugün env -S’yi ilk kez öğrendim ve yazıdaki shebang’i görür görmez “Linux’ta çalışmaz; çünkü shebang yalnızca tek bir argüman geçirebilir” diye düşündüm.
Örneğin
#!/usr/bin/env -S uv run --scriptile başlayanfoo.pyçalıştırıldığında işletim sistemi aslında tüm shebang satırını tek bir argüman olarak/usr/bin/env '-S uv run --script' foo.pygibi geçirir.Ama
enviçindeki-S, o dizgeyi yeniden birden çok argümana böldüğü için çalışır. Çok şık ve kullanışlı.#!/usr/bin/guile \satırından sonra gelen satıra-e main -skoyup!#ile kapatırsanız/usr/bin/guile -e main -s filenamegibi olur.Bunu neden özellikle böyle yaptıklarını merak ediyorum. Muhtemelen
env -Syakın zamanda eklenmişti ya da ilgilendikleri tüm platformlarda kullanılamıyordu.https://www.gnu.org/software/guile/manual/html_node/The-Meta-Switch.html
make’e benzeyen ama yapılandırma için YAML kullanan bir Go CLI’ı olan tusk ile bu yöntemi kullanmak iyi oluyor.Shebang olarak
#!/usr/bin/env -s go run github.com/rliebz/tusk@latest -fkoyup yorumlayıcı olarakinterpreter: go run mvdan.cc/sh/v3/cmd/gosh@latest -sşeklinde Go shell’i olan gosh’u kullanıyorsunuz.Böylece yalnızca Go kuruluysa her mimaride çalışabilen bir CLI elde ediliyor.
Örneğin nix-shell,
#!/usr/bin/env nix-shellsatırından sonra#!nix-shell --pure -i runghc ./default.nixsatırını koyarak bağımlılıkları ve argümanları belirtebilir; ardından Haskell kodunu yazmaya devam edebilirsiniz.Shebang satırındaki tuhaf boşlukla ayırma kuralları, düzeltilemeyen eski bir hatanın Unix’in kalıcı bir kusuruna dönüşmüş hâli.
Yukarıdaki gibi geçici çözümleri her kullandığımda, 1980’lerde buna 30 dakika ayrılsaydı sonraki yıllarca süren sinir bozukluğundan kaçınılabilirdi diye düşünüyorum. Shebang satırı en başından
/bin/shgibi ayrıştırılmalıydı.Shebang değil ama son zamanlarda uv’yi kurulum aracı gibi kullanıyorum.
Karmaşık bağımlılıkları olan Python CLI araçlarını paketlemek ve dağıtmak zor olduğu için iki şekilde yararlandım.
Biri,
curl | shkurulum betiğini kopyalayıp sonunauv tool install --python python3.12 my-toolekleyerek kullanıcının CLI’ı tek satırla kurmasını sağlamak; diğeri ise yalnızcauvbağımlılığı olan küçük bir PyPI “kurucu” paketi oluşturupuv tool installçalıştırmasını sağlamak.İki yöntem de CLI aracını, Python 3.12’yi ve tüm Python bağımlılıklarını yalıtılmış bir ortama kuruyor. Kullanıcının sanal ortam yönetmesine gerek kalmıyor;
curl | shyönteminde Python’ın kurulu olması bile gerekmiyor.Bundan sonra kullanıcıların karmaşık bağımlılıkları bozmasından kaynaklanan GitHub issue’ları belirgin biçimde azaldı.
Ayrıntılar ve kod bağlantısı: https://aider.chat/2025/01/15/uv.html
openssl-dev,gzip,ffigibi kütüphane header’ları gerekmez ve Python’ı derlemek zorunda kalınmaz mı diye düşünüyorum.En azından ASDF-VM kullanırken, içerideki başka Python kurulum araçları yüzünden böyle bir deneyim yaşamıştım.
miseveaquada da yararlı bir araç kurulumu kavramı var gibi görünüyor.İlginç shebang konusu açılmışken, Prolog
.pldosyalarını kabuktan çalıştırmak için şöyle bir şey yapmıştım/*usr/bin/env scryer-prolog "$0" "$@" ; exit #*//**/yorumları olan ama#yorumlarını ya da#!shebang’i doğrudan desteklemeyen betik dillerinde genel olarak çalışacak gibi görünüyorOrijinal yorum: https://github.com/mthom/scryer-prolog/issues/2170#issuecomment-1821713993
Bu dosya hem geçerli bir shell dosyası hem de geçerli bir Prolog dosyası. Shell olarak çalıştırıldığında ilk satır glob deseni
/*usr/bin/envile/usr/bin/envyi bulup çalıştırıyor;envdescryer-prolog "test.pl"yi çalıştırıyor. Prolog tarafında ise ilk satır/* ... */yorumu olduğu için yok sayılıyorArdından shell,
;sonrasındakiexiti çalıştırarak geri kalan Prolog kodunun shell olarak yorumlanmasını engelliyor;#ise shell’in Prolog yorum kapatıcısı*/yi yok saymasını sağlayıp hata çıktısını önlüyorYaptığım şeyler arasında en iyisi ve en kötüsü olabilir
Buna ek olarak C programları da
//usr/bin/env sh -c ...biçimindeki bir ilk satır kullanılarak çalıştırılabilir hâle getirilebilir. Çalıştırma sırasındamakeile derleyip ortaya çıkan ikiliyi çalıştırdığı için, kaynağı değiştirip yeniden çalıştırdığınızda değişen çıktı hemen görünür#!/bin/shsatırının ardından# the next line restarts using tcl \satırı konupexec tclsh "$0" "$@"çalıştırılacak hâle getirilebiliyorBu, TCL’de yorum satırlarında da satır devamı yapılabilmesinden yararlanıyor
Trey Hunner’ın Lazy self-installing Python scripts with uv yazısında örneklerle birlikte daha ayrıntılı bilgi var
https://treyhunner.com/2024/12/lazy-self-installing-python-scripts-with-uv/
printf %.1s 0{1..80} $'\n'ya dafor i in {1..80}; do echo -n 0; done; echoile yapılabilirffmpeg örneğinin de
ffmpeg -i in.mp4 -c:v copy -filter:a volumedetect -pass 1 -f null /dev/null && ffmpeg -i in.mp4 -c:v copy -filter:a "loudnorm" -pass 2 out.mp4den ne farkı var pek anlayamadımAçıkçası Python tarafı daha karmaşık görünüyor
Küçük işler için bu püf noktasını mise (mise-en-place) ile birlikte kullanabilirsiniz: https://mise.jdx.dev/tasks/toml-tasks.html#shell-shebang
toolsiçindeuv = 'latest'koyup, görevinrunbloğunda#!/usr/bin/env -S uv run --scriptvedependencies = ["requests<3", "rich"]tanımladıktan sonra Python kodunu ekleme yöntemi16 gün önce de ilgili bir yazı ve tartışma vardı: Uv's killer feature is making ad-hoc environments easy https://news.ycombinator.com/item?id=42676432 (502 puan, 417 yorum)
Akılda tutulmaya değer bir püf noktası
Son zamanlarda Python takma adımı
uv run pythonolarak değiştirdim ve oldukça rahat..venvvb. yönetmeye gerek kalmıyor; sistem kurulumu ya da global/kullanıcı kurulumu sorunlarıyla da uğraşmıyorsunuz, Debian’da özellikle işe yarıyorBir proje ya da ortam içinde REPL çalıştırırken de
activateolmadan çağırabildiğiniz için düşünmeniz gereken şeyler azalıyorAncak
.pydosyasını uv ile doğrudan çağırırken proje/ortam dosyası yolu,.pydosyasının konumuna göre değil, mevcut çalışma dizinine göre belirleniyor; bu bir dezavantaj--projectadlı açık bir seçenek var veuv run --project /script.pygibi kullanılabiliyor; ama hedef dosyaya göre göreli bir proje seçeneği olsaydı tekrarı azaltacağı için iyi olurduuvveyauvxi komut çalıştırıcısı olarak kullanırken birkaç tuzakla karşılaştım, ama çoğu zaman iyi çalışıyor; çalıştığında da ciddi ölçüde zaman kazandırıyorBir Python geliştiricisi ve meraklı biri olarak ev dizinim sığ klonlar ve tek seferlik test dizinleriyle dolu; bu tür yönetim yükünü azaltması gerçekten faydalı
Bu fikri çalıp kullanmak istiyorum.
.pyolmayan ayrı bir uzantı mı kullandığını, yoksa.pydosyasında çalıştırma biti açık ve shebang bulunmasının, bunun sistem Python'ıyla değil doğrudan betik olarak çalıştırılabileceğinin işareti sayılıp sayılmadığını merak ediyorumSıfır değil, ama oldukça dikkatli arıyorum. Hangi tuzaklarla karşılaştığını öğrenebilirsem listeye eklemek isterim
.pydosyasına çalıştırma biti ve yazıdaki shebang satırı eklenerek kullanılıyorPipenv'de belirli bir bağımlılığın platforma göre farklı wheel'leri olduğunda sorun yaşanmıştı; Poetry'de ise düzgün çalışmıştı
Pipenv'in kilit dosyası yalnızca kilitlenen platformun bağımlılıklarını içeriyordu, Poetry ise tüm platform varyantlarını kilit dosyasına ekliyordu
uv'nin bu durumda nasıl davrandığına dair dokümanları henüz bulamadım
İşin özü şu
Yakın zamanda yayımlanan bir PEP, Python betiklerinin başlangıç yorumlarında bağımlılıklarını nasıl bildireceğini tanımlıyor; uv ise bu bağımlılıkları tarayıp karşılayan ve ardından ilgili modüller içe aktarılabilir durumdayken betiği çalıştıran bir Python betik çalıştırıcısı ve paket yöneticisi
Python betiğinin ilk satır yorumu olan shebang'de dosyayı
pythonyerineuvile çağıracak şekilde ayarlarsanız, betiği “çalıştırdığınızda” bu etkiyi otomatik olarak elde ediyorsunuzSonuç olarak, kurulum gerektiren bağımlılıkları olan Python betikleri de doğrudan çalışıyor
$PATHiçinde uv'nin kurulu olması gerekiyorAyrıca uv bağımlılıkları kuracak olsa da, bu yöntemle Python yorumlayıcısını da otomatik kurup kurmadığı net değil
Kişisel olarak bunun eski usulle ortam oluşturup çağırmaktan zaman kazandırdığını düşünmüyorum
uv'nin ortamı etkileşimli oturumlarda da yükleyip yükleyemediğinden, yoksa yalnızca betik çalıştırmak için mi kullanıldığından da emin değilim
TypeScript'i seviyorsanız aynı yaklaşımı Deno ile de kullanabilirsiniz. Bun ile de olur gibi, ama bizzat denemedim
#! /usr/bin/env -S deno runşeklinde kullanılır; izin bayrakları gerekiyorsa#! /usr/bin/env -S deno run --allow-env --allow-read --allow-netgibi eklenebilir