Memanfaatkan Skrip Python dengan uv dan PEP 723

(cottongeeks.com)

14 poin oleh GN⁺ 2025-06-25 | 2 komentar | Bagikan ke WhatsApp

Manajer paket uv dan PEP 723 memungkinkan eksekusi skrip Python tanpa masalah dependensi
Fitur uvx secara otomatis membuat virtual environment disposable sehingga mengatasi kerepotan pengaturan lingkungan
Jika metadata PEP 723 disertakan di file Python, eksekusi otomatis skrip dan pengelolaan paket menjadi lebih praktis
Sebagai contoh skrip eksekusi, program ekstraksi subtitle YouTube dapat diimplementasikan dan didistribusikan dengan cepat
Dengan ini, Python kini juga memungkinkan penulisan file eksekusi tunggal yang ringkas, sehingga kegunaan skrip meningkat drastis

Gambaran umum

Ketidaknyamanan karena harus melalui proses pengaturan lingkungan dan instalasi paket setiap kali menjalankan "skrip sekali pakai (one-off)" di Python kini hilang berkat hadirnya uv dan PEP 723
uv adalah manajer paket dan proyek Python berkecepatan tinggi yang dikembangkan dengan Rust, dan bersama fitur baru uvx dapat menangani pembuatan virtual environment disposable, instalasi paket otomatis, serta pengaitan versi Python dengan sangat cepat dan mudah

Kelebihan uv dan uvx

Fitur uvx bekerja mirip npx di ekosistem Nodejs, dengan cepat membuat lingkungan eksekusi untuk paket Python tertentu (misalnya ruff)
Memanfaatkan disposable virtual environment sebagai cache sehingga memberikan eksekusi cepat tanpa overhead
Pengaturan lingkungan dan instalasi dependensi cukup dilakukan dengan satu baris perintah, sehingga developer tidak perlu mengelola konfigurasi lingkungan secara terpisah

Pengenalan dan pemanfaatan PEP 723

PEP 723 menetapkan standar agar metadata dependensi dan lingkungan dapat disertakan di bagian atas skrip Python
Contoh: requires-python, dependencies, dan sebagainya dapat dituliskan di bagian atas kode
Tool eksternal yang mengenalinya (seperti uv) akan menggunakan informasi di dalam file skrip untuk menangani instalasi otomatis, pengaturan lingkungan, dan eksekusi

Kombinasi uv dan PEP 723

Dengan menuliskan metadata tersebut di bagian atas file contoh Python dan menjalankannya memakai perintah uv run, semua paket yang diperlukan akan langsung terinstal otomatis, versi Python yang ditentukan akan disiapkan, lalu kode dijalankan
Kode contoh memanggil API internet (daftar PEP) dan menampilkan hasilnya. Semua itu dapat dijalankan dalam satu baris tanpa instalasi paket tambahan atau konfigurasi lingkungan

Contoh praktis: skrip subtitle YouTube

Disediakan contoh skrip Python yang menambahkan shebang (#!/usr/bin/env -S uv run --script) dan metadata PEP 723
Paket eksternal seperti youtube-transcript-api akan dipasang otomatis dan virtual environment juga disiapkan secara otomatis
Pengguna cukup memberikan URL atau ID video YouTube sebagai argumen ke file eksekusi (ytt), lalu subtitle akan diekstrak dan hasilnya langsung diberikan
Setelah memberi izin eksekusi dengan chmod, skrip dapat dijalankan dengan mudah dari terminal

Peningkatan pengalaman developer dan perluasan kemungkinan

Dulu, bahkan untuk menjalankan skrip sederhana, bahasa yang menghasilkan binary eksekusi tunggal seperti Go sering lebih disukai, tetapi kini Python juga menawarkan kemudahan pada tingkat yang setara
Kombinasi uv dan PEP 723 membuat berbagi, mendistribusikan, dan mengotomatisasi eksekusi skrip Python menjadi jauh lebih mudah
Contoh di Github (cottongeeks/ytt-mcp) menunjukkan bahwa use case yang lebih kompleks juga dapat dikembangkan

2 komentar

ndrgrd 2025-06-25

uv memang sangat cepat, jadi enak dipakai. Belakangan ini saya menggunakannya di semua tempat yang memungkinkan.

GN⁺ 2025-06-25

Opini Hacker News

Seperti penulis postingan, belakangan saya lebih sering memilih Python lintas platform untuk one-off dan skrip pribadi daripada Go, tetapi saya tetap kurang puas karena sistem type checking Python benar-benar kacau; saya berharap tool seperti ty dan pyrefly bisa sedikit memperbaiki situasi ini
Sekarang rasanya skrip Python bisa langsung berjalan dengan baik tanpa harus repot karena virtualenv Saya juga berharap pengalaman seperti ini bisa hadir di dunia shell script Packaging, manajemen dependensi, dan reproduksibilitas masih terasa seperti zaman batu Realitanya sekarang masih antara pasrah dengan curl | bash, atau hanya diberi file README berisi 3 dependensi yang hilang dan 12 langkah manual Nix? Rasanya itu pilihan yang berguna hanya untuk orang yang sudah melampaui waktu, ruang, dan manual Nix Docker? Kalau menurut Anda mengunduh distribusi Linux hanya untuk menjalankan satu perintah sed itu masuk akal, silakan saja Saya merasa kita benar-benar butuh titik tengah yang sederhana, deklaratif, dan mudah dipakai semua orang
- Saya pribadi lebih suka hanya menulis shell script yang memakai biner dan library bawaan yang memang sudah tersedia di OS target Tujuan membuat shell script portabel pada praktiknya terasa seperti pilihan yang tidak cocok Kalau Anda harus menjalankan shell script yang memakai perintah khusus macOS di Linux, tidak ada package manager yang bisa menyelesaikan masalah itu
- Nix untuk tujuan ini rasanya tidak sesulit itu dari sisi penggunaan Jika Nix dipasang di distro lain, penggunaannya bisa sesederhana ini Memang NixOS atau keseluruhan packaging Nix cukup menantang, tetapi jika hanya dibatasi pada shell script, hambatan masuknya relatif rendah
- Saya sendiri tidak merasa perlu menulis shell script baru Kalau berada di lingkungan yang mengizinkan pemasangan semua dependensi, tool seperti uv bisa menangani semuanya Jika Anda suka Clojure, babashka juga layak direkomendasikan
- Alasan packaging, manajemen dependensi, dan reproduksibilitas di shell script terasa kuno adalah karena jika Anda sudah membutuhkannya, kemungkinan shell memang bukan alat yang tepat Menurut saya shell hanya cocok untuk skrip kecil sekitar 20 baris Bahasanya sendiri tidak cukup bagus untuk skala yang lebih besar dari itu
- Rekomendasi untuk mise Di kantor kami memakainya untuk mengelola environment pengembangan, dan setup environment jadi jauh lebih sederhana dibanding Docker maupun Nix Dukungan instalasi paralel juga terasa sebagai keunggulan besar dibanding Dockerfile biasa
Ini benar-benar tren yang keren dan terasa makin populer Saya pertama kali mengetahuinya dari blog simonw, dan bisa melihat bahasannya di posting blog simonwillison Pada bulan Maret tahun ini juga ada diskusi Hacker News dari posting blog lain Saya berharap tren ini bisa bertahan lama di halaman utama agar lebih banyak orang menyadarinya
Setelah mencoba uv untuk proyek kecil, pengalamannya benar-benar luar biasa Kombinasi uv run dan uv tool run (uvx) membuat proses memasang dan langsung menjalankan skrip Python dari GitHub di VM menjadi sangat sederhana Tidak perlu git clone, tidak perlu membuat atau masuk ke venv, dan tidak perlu pip install Yang paling penting, uv sangat cepat sampai awalnya terasa seperti ada yang salah; kenyataannya hasilnya memang 10x lebih cepat daripada pip Memang tool dan dokumentasinya masih sedikit belum matang, tetapi dengan tingkat inovasi dan kepraktisan seperti itu, menurut saya tetap sangat layak dipakai
- Saya sungguh kagum karena uv benar-benar memasang dependensi lebih cepat daripada waktu yang dibutuhkan pyenv untuk menampilkan --help
Rust juga sedang mengembangkan ide shell script tipe single-file yang mirip seperti ini Saya pertama kali melihat pendekatan seperti ini di Rust, termasuk dukungan menjalankan satu file dengan manajemen dependensi Saya berharap pola ini bisa mapan di lebih banyak bahasa, karena sangat berguna untuk dibagikan lewat gist atau untuk menulis tool kecil dengan cepat Lihat juga dokumen RFC cargo-script
- C# juga mendukung fitur ini: pengumuman resmi dotnet-run-app
Saat menggunakan uv run --script dan metadata disertakan di dalam skrip, agak kurang nyaman untuk langsung membuka Python REPL dari skrip lalu menguji perubahan Misalnya harus seperti ini,
```
$ uv run --python=3.13 --with-requirements <(uv export --script script.py) -- python
>>> from script import X
```
Saya berharap ada cara yang lebih ringkas Misalnya akan sangat ideal kalau bisa seperti
```
$ uv run --with-script script.py python
```
Namun pada praktiknya, kalau dijalankan seperti di bawah ini, kita bisa langsung masuk ke Python dan environment venv yang sesuai untuk skrip tersebut
```
$ "$(uv python find --script script.py)"
>>> from script import X
```
Hanya saja, environment-nya tetap perlu dibuat terlebih dahulu dengan menjalankan skrip setidaknya sekali
- Jika Anda membutuhkan fitur untuk memanggil REPL setelah setup, saya merekomendasikan contoh gist ini Anda bisa menambahkan flag seperti --interactive ke dalam skrip dan menjadikannya opsi CLI Saya cukup sering menulis CLI kecil berbasis Typer dengan cara seperti ini Dalam skrip dev, saya juga pernah memakai flag --sql untuk masuk ke DuckDB SQL REPL
- Ada satu cara sederhana yang diperkenalkan
```
cat ~/.local/bin/uve
#!/bin/bash
temp=$(mktemp)
uv export --script $1 --no-hashes > $temp
uv run --with-requirements $temp vim $1
unlink $temp
```
Jika memakai conda, Anda bisa langsung mengaktifkan environment dari shell wrapper untuk skrip Python Tulis seperti berikut
```
#!/usr/bin/env bash
eval "$(conda shell.bash hook)"
conda activate myenv
python myscript
```
Namun ini bukan pendekatan yang mandiri seperti gaya PEP 723
Setelah melihat thread HN kemarin dan hari ini, saya akhirnya memutuskan mencoba uv untuk pertama kalinya, dan sangat terkesan dengan kecepatannya serta kemudahan manajemen dependensi Akan lebih baik jika dokumentasi resminya ditingkatkan, terutama jika ada panduan berpindah dari alur kerja requirements.txt ke uv Ada juga bagian yang membingungkan soal penetapan versi Python per proyek (.python-version dan pyproject.toml sama-sama mendefinisikannya)
- Saya punya pengalaman menulis ebook penjelajah tool pengembang Python Saya pernah membahas bagian-bagian yang kurang dijelaskan di dokumentasi resmi, cara migrasi dari requirements.txt dan cara mengubah versi Python proyek uv juga layak dilihat Jika ada topik lain yang ingin dibahas, silakan usulkan kapan saja
- Field requires-version di pyproject.toml berarti rentang versi yang dijamin kompatibel, sedangkan .python-version menetapkan versi spesifik yang dipakai untuk pengembangan Saat dibuat dengan uv init, awalnya keduanya mungkin tampak sama, tetapi seiring waktu requires-version akan menetapkan versi minimum yang didukung yang lebih rendah daripada .python-version requires-version juga masuk ke metadata paket dan memengaruhi resolusi dependensi bagi orang lain yang menggunakan paket yang Anda distribusikan Misalnya ketika v1 masih mendukung Python 3 versi lama tetapi v2 tidak lagi
- Saya juga merasakan hal serupa, tetapi tetap bersikeras dengan workflow saya sendiri: file yang sama disinkronkan ke semua komputer lewat Dropbox dan dipakai tanpa memedulikan platform Seperti npm atau dotnet, saat berganti platform memang perlu npm update atau dotnet restore, tetapi venv tetap bekerja dengan baik tanpa masalah Sebaliknya, uv terasa lebih rumit dan perlu pembersihan manual ketika berpindah platform seperti ini
- pyproject.toml (terlepas dari uv sendiri) dipakai untuk mendefinisikan environment yang diperlukan saat Anda membagikan kode ke pengembang dan pengguna lain Saat membangun paket untuk PyPI, file itu menjelaskan environment apa yang dibutuhkan, dan rentang versinya diatur agar lebih banyak orang bisa memakai ulang kode tersebut .python-version hanya dipakai oleh uv, dan hanya sebagai acuan saat menyiapkan environment pengembangan saya Jika Anda sudah memiliki environment yang siap, tidak masalah jika tidak membuatnya lagi uv memang belum menjadi build backend resmi, tetapi sedang menyiapkan fitur itu (issue #3957)
- Saya belum pernah menelitinya secara detail, tetapi saya menduga peran file .python-version lebih untuk kompatibilitas dengan tool lain yang tidak punya parser TOML
Dulu saya pernah ingin membuat tool yang membuat skrip Python bisa memasang dependensinya sendiri (Targetnya adalah tool yang bekerja seperti uvx, tetapi bisa berjalan hanya dengan Python yang sudah ada) Namun kekurangannya adalah harus menambahkan beberapa baris aneh di bagian awal skrip Kalau penasaran, tool itu dirilis di PyPI dengan nama pysolate
- Ada juga proyek isolate yang mirip tetapi tidak banyak dipakai Pendekatannya sedikit berbeda, tetapi tetap contoh yang menarik
Pesan bergaya Grace Hopper yang terinspirasi dari COBOL Ada pendapat bahwa semua program Python seharusnya memiliki ENVIRONMENT division yang mendefinisikan dengan jelas environment kompilasi dan eksekusi, termasuk kebutuhan hardware dan software Struktur seperti ini dianggap akan sangat berpengaruh dalam meningkatkan portabilitas program di berbagai sistem