Mengapa Railway Beralih dari Nix ke Railpack

 (blog.railway.com)
1 poin oleh GN⁺ 2025-06-09 | 1 komentar | Bagikan ke WhatsApp
  • Railway mendesain ulang builder yang membuat image container dari kode pengguna, memindahkan pengalaman dari Nixpacks yang telah membangun lebih dari 14 juta aplikasi ke Railpack
  • Nixpacks cukup untuk 80% pengguna, tetapi 200 ribu pengguna Railway lainnya bisa terbentur keterbatasan dalam manajemen versi, ukuran image, dan caching
  • Railpack meningkatkan reproduksibilitas build dengan versi major.minor.patch, penguncian dependensi, dan alur instalasi berbasis Mise, alih-alih manajemen versi berbasis commit milik Nix
  • Dengan menghasilkan BuildKit LLB dan Frontend secara langsung, image Node default menjadi 38% lebih kecil dan image Python default menjadi 77% lebih kecil, sekaligus memungkinkan cache yang bisa dibagikan antar lingkungan
  • Railpack saat ini tersedia dalam Beta dan bisa diaktifkan di pengaturan layanan, sementara Railway lebih memprioritaskan kematangan bahasa yang paling sering dipakai dibanding dukungan bahasa yang luas

Latar belakang Railway membuat builder baru

  • Railway memperkenalkan Railpack sebagai tahap berikutnya dari builder Railway
  • Railpack dikembangkan ulang dari nol berdasarkan pengalaman membangun lebih dari 14 juta aplikasi dengan Nixpacks
  • Nixpacks dirilis sekitar 3 tahun lalu dan kemudian menjadi cara default di Railway untuk membangun image dari kode pengguna
  • Ini bekerja baik untuk 80% dari seluruh pengguna, tetapi 200 ribu pengguna Railway sisanya bisa mengalami keterbatasan
  • Railway menilai bahwa untuk menumbuhkan basis pengguna dari 1 juta menjadi 100 juta, builder perlu ditingkatkan secara besar-besaran

Keterbatasan yang dihadapi Nixpacks di Nix

  • Masalah terbesar adalah manajemen versi paket berbasis commit di Nix
    • Setiap paket hanya menyediakan versi major terbaru
    • Versi terikat pada commit tertentu di repo nixpkgs
  • Upaya untuk mendukung semua versi patch akhirnya menjadi struktur yang memetakan string versi langsung ke commit SHA, yang tidak jelas atau sulit dipelihara bagi kontributor yang tidak terbiasa dengan manajemen versi Nix
  • Bahasa seperti Node dan Python pada akhirnya hanya mendukung versi major terbaru
  • Jika commit SHA diperbarui untuk mendukung versi paket terbaru, versi paket lain juga bisa ikut berubah
    • Jika versi default berubah, build pengguna yang sebelumnya berjalan bisa gagal karena error tak terduga
    • Railway menganggap situasi build yang tadinya berhasil lalu tiba-tiba rusak lebih buruk daripada pengguna tidak bisa mengakses paket terbaru

Masalah ukuran image dan caching

  • Cara Nixpacks mengambil dependensi dengan Nix sering kali menghasilkan ukuran image yang besar
  • Nix serta paket dan library terkait yang diperlukan untuk build dan runtime masuk ke dalam satu layer /nix/store
  • Karena tidak ada cara untuk memisahkan dependensi Nix ke layer terpisah, ada batasan dalam mengurangi ukuran image akhir
    • Railway menilai ini bukan masalah Nix itu sendiri, melainkan masalah cara Nix digunakan di Nixpacks
  • Caching juga sulit dikendalikan karena sulit mengatur kapan cache layer menjadi tidak valid
  • Railway menyuntikkan variabel lingkungan deployment ID ke semua build
    • Di Dockerfile, layer yang dijalankan setelah variabel ini ditambahkan akan selalu tidak valid dan tidak bisa di-cache
  • Pendekatan menyembunyikan elemen inti Nix dari pengguna juga tidak terlalu cocok
    • Railway tidak ingin pengguna harus memahami apa itu derivation, atau mengapa Node 22.14.0 berada di versi archive tertentu dari channel unstable

Perubahan struktural di Railpack

  • Railway membuat Railpack untuk mengatasi masalah yang dialami di Nixpacks
  • Seiring keluar dari Nix, namanya pun berubah dari Nixpacks menjadi Railpack
  • Codebase berpindah dari Rust ke Go karena library BuildKit
  • Railpack memberi kontrol yang lebih langsung atas cara image akhir dibuat
    • Menghasilkan BuildKit LLB dan Frontend secara langsung
    • Dibanding Nixpacks, image Node default menjadi 38% lebih kecil dan image Python default menjadi 77% lebih kecil
    • Menggunakan Mise untuk interpretasi versi dan sebagian besar instalasi paket
    • Menyisakan kemungkinan untuk mendukung sumber executable lain di masa depan
  • Dependensi yang digunakan pada build yang berhasil bisa dikunci
    • Ini memungkinkan build tetap tidak rusak meski versi Node default berubah dari 22 ke 24
  • Menggunakan BuildKit secrets agar variabel lingkungan rahasia tidak muncul di log build atau image akhir

Cara kerja build Railpack

  • Proses Railpack dibagi menjadi tiga tahap
    • Analyze: melihat kode untuk menentukan paket yang akan diinstal, perintah yang akan dijalankan, dan perintah start
    • Plan: membuat rencana build yang bisa diserialisasi ke JSON dan terdiri dari beberapa langkah, di mana setiap langkah mengambil input dari langkah lain atau dari keseluruhan image
    • Generate: menyusun graph build BuildKit berdasarkan input dan output dari rencana
  • Dockerfile bersifat linear, tetapi graph BuildKit disusun jauh lebih paralel
  • Setiap perintah dijalankan pada stage tersendiri dalam multi-stage build, sehingga kontrol terhadap layer input dan cara perakitan filesystem akhir bisa dilakukan secara rinci
  • Railpack menghasilkan rencana build yang memuat semua langkah build yang dibutuhkan
    • Setiap langkah mendefinisikan secara spesifik langkah atau image sebelumnya yang dibutuhkan
    • Format ini lebih low-level dibanding pendekatan yang digunakan di Nixpacks
    • Rencana tersebut diterjemahkan dan dieksekusi sebagai graph berformat LLB
  • BuildKit bekerja dari bagian akhir ke awal, mengambil dari cache jika memungkinkan, dan hanya menjalankan perintah saat diperlukan untuk menyelesaikan layer yang diminta
  • Untuk membuat layer tidak valid saat variabel lingkungan tertentu berubah, Railpack meng-hash nilai variabel yang digunakan dan me-mount file berisi hash itu ke filesystem input
    • Jika kode dan variabel yang digunakan tidak berubah, cache layer akan tetap kena
  • Railpack bisa mendefinisikan sepenuhnya bagaimana image dibuat

Hal yang dimungkinkan oleh Railpack

  • Bisa membangun dan men-deploy situs statis Vite, Astro, CRA, dan Angular tanpa konfigurasi
  • Integrasi antara build dan Railway UI menjadi lebih erat
  • Bisa mendukung versi terbaru suatu bahasa tanpa perlu rilisan Railpack
  • Bisa menggunakan layer caching yang dioptimalkan di beberapa environment proyek

Cara penggunaan saat ini dan cakupan dukungan

  • Railpack saat ini tersedia dalam Beta dan dapat diaktifkan di pengaturan layanan
  • Sudah digunakan untuk build railway.com dan central station
  • Dukungan saat ini mencakup:
    • Node
    • Python
    • Go
    • PHP
    • Deploy Static HTML
    • Dukungan bawaan untuk situs statis Vite, Astro, CRA, dan Angular
  • Railway menargetkan lingkungan yang memudahkan deployment frontend dan backend
  • Dukungan framework dan bahasa terus ditambahkan
    • Permintaan dapat disampaikan melalui Help Station
    • Sampai API inti dan abstraksi benar-benar ditetapkan, Railway memprioritaskan kedalaman untuk bahasa yang paling sering digunakan daripada dukungan yang luas
  • Railpack bersifat open source dan dokumentasinya tersedia di railpack.com

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-09
Komentar Hacker News

  • Saya penggemar Nix, tetapi bukan berarti ingin mengkritik Railway karena menjauh dari Nix. Hanya saja, beberapa keluhannya tampaknya perlu penjelasan lebih lanjut.
    Nixpkgs itu luar biasa, tetapi tidak sama dengan Nix; dan jika ingin mengambil toolchain versi arbitrer, Nixpkgs memang bukan pilihan ideal. Alat Nix untuk mengambil versi Rust arbitrer sudah sangat bagus, dan berbagai alat pengembangan berbasis Nix lain juga menunjukkan cara menangani hal ini dengan baik.
    Saya juga tidak paham pernyataan bahwa “tidak ada cara untuk memisahkan dependensi Nix ke layer terpisah.” Anda bisa saja memisahkannya dengan cara apa pun yang diinginkan, dan alat Docker bawaan Nixpkgs juga punya sebagian dukungan untuk itu.
    Perpindahan dari Rust ke Go tidak terkait langsung dengan Nix, tetapi menarik; dan ini juga terdengar seolah Railpacks dan Nixpacks dibuat oleh orang yang berbeda. Saya pernah melihat hal yang cukup buruk terjadi ketika orang-orang yang tidak akrab dengan Nix harus menanggung solusi Nix setengah jadi di dalam organisasi, jadi di tempat kerja biasanya saya tidak memakai Nix agar tidak menciptakan situasi seperti ini.

    • Saya tidak memakai Nix, tetapi tanggapan “Nixpkgs bukan Nix” terdengar agak dismissive. Jika Nixpkgs adalah default dan alternatifnya membutuhkan riset serta usaha tambahan, maka bagi kebanyakan pengguna, secara praktis itulah Nix.
      Pernyataan “pisahkan layer sesuai keinginan” juga bergantung pada apakah hal itu jelas, sederhana, dan merupakan perilaku default.
    • Setiap kali masalah usability dasar di Nix muncul, jawaban “ada workaround” terus berulang, dan itu melelahkan. Workaround itu membutuhkan pengetahuan turun-temurun, harus menulis puluhan hingga ratusan baris dalam bahasa yang bekerja sangat berbeda dari bahasa arus utama, sementara pesan error dan dokumentasi standard library-nya juga tidak bagus.
      Alasan orang mengeluh tentang Nix bukan karena ia tidak Turing-complete, melainkan karena ia tidak menyediakan API kelas satu yang sederhana dan langsung cocok dengan proyek idiomatis di ekosistem terkait, sehingga menciptakan lebih banyak masalah daripada yang diselesaikannya.
      Jika setiap proyek yang ingin memakai Nix pada akhirnya mengarah pada penulisan modul sendiri untuk memperbaiki masalah Nix, alasan untuk memakai Nix ketimbang alat arus utama yang dokumentasinya bagus menjadi lemah. Dalam kasus ini pun tampaknya persis begitu, dan kebanyakan orang sepertinya akan memilih Docker saja.
      Menjengkelkan melihat produk untuk developer lebih terpaku pada flakes yang murni secara ideologis daripada menyelesaikan masalah pengalaman developer yang praktis dengan kecepatan yang bukan skala waktu geologis. Saya paham ini kontribusi sukarela, tetapi sangat disayangkan begitu banyak upaya teknis masuk ke sesuatu yang pengalaman penggunanya buruk hingga secara praktis sulit dipakai.
    • Bagian yang mudah terlewat adalah bahwa pengguna Railway adalah developer yang ingin menentukan dependensi dan versi mereka sendiri untuk paket arbitrer.
      Dalam cara Nix bekerja bersama struktur Nixpkgs, mengunci versi suatu paket berarti mengunci commit seluruh tree nixpkgs. Build paket node/python/ruby juga bergantung pada keadaan tree di luar direktori paket, sehingga perlu pemetaan antara versi dan commit.
      Karena abstraksi ini bocor, Railway harus mengeksposnya kepada pengguna; pengguna yang sebenarnya hanya ingin menjalankan yarn add new-fancy-nodejs-package-with-linked–native-deps bisa saja tersandung pada kebutuhan menyelaraskan berbagai keadaan repositori nixpkgs.
      Untuk penggunaan yang cakupannya sempit, memakai Nix tanpa Nixpkgs mungkin baik-baik saja, tetapi pada platform seperti Railway tampaknya sulit dibenarkan.
    • Saya juga mendengar ucapan semacam “Nix != Nixpkgs” terkait FreeBSD ports ketika mencoba FreeBSD. pkg umumnya bekerja dengan baik, tetapi suatu hari saat mencoba mengompilasi vim dari ports dengan flag USE kustom, ia menarik lebih dari 20 dependensi dan menanyakan opsi di setiap make menuconfig, lalu paket ke-16 dari 23 gagal dengan pesan semacam “ini butuh itu, dan itu butuh Fubar3.32.1, tetapi Fubar3 sudah deprecated menjadi Fubar4,” jadi saya menyerah.
      Saya paham para developer Core OS tidak bisa mendukung lebih dari 10 ribu paket semuanya, tetapi juga harus dibuat jelas bahwa ketika benar-benar mencoba mengaktifkan fitur kustom, peluang gagalnya tinggi. Atau lebih baik tetapkan kriteria bahwa build standar yang dibuat secara independen harus berhasil sebelum muncul di ports, dan singkirkan dari daftar ports apa pun yang tidak bisa dikompilasi.
    • Menurut saya ini dirangkum dengan baik. Sebagai tambahan, walaupun nixpkgs bukan Nix itu sendiri, nixpkgs juga merupakan bagian yang bagus. Sejak memakai NixOS, untuk pertama kalinya saya memakai versi terbaru kernel Linux pada hari rilisnya, dan itu cukup hebat. Seiring bertambah usia, saya juga mulai menerima Debian Stable, tetapi selalu terasa seperti kembali beberapa tahun ke belakang.
      Bahasa Nix bisa dikritik berjam-jam, tetapi ia sudah tua, merupakan upaya terbaik pada masanya, dan sekarang mungkin tidak terlalu sepadan untuk diubah. Sistem build Nix terasa cukup primitif, dan sering membangun ulang hal-hal yang tampaknya tidak perlu dibangun ulang. Misalnya, sebagian besar build ISO instalasi NixOS bergantung pada command line yang diberikan ke kernel, console=ttyS2,1500000n8, sehingga mengubah kecepatan port serial saja membutuhkan build sekitar 3 menit. Memang lucu, tetapi ini tidak membuat saya berhenti memakai Nix; hanya saja, hal semacam ini tidak akan saya izinkan dalam build saya sendiri.
      Menurut saya pribadi, Nix untuk image Docker adalah area terlemah Nix. Dulu saat membuat software Go, saya perlu menambahkan binary pg_dump dari Postgres ke image container. Mengikuti saran tim infra, saya memakai Nix, dan image binary Go terkompresi 50MB berubah menjadi 1,5GB entah berisi apa. pg_dump sendiri 464KB. Akhirnya saya memakai Bazel dan rules_debian untuk menginstal paket apt, dan hasilnya jauh lebih rapi serta kecil di atas distroless. Berdasarkan pengalaman nyata dengan Nix, rasanya sistem Nix selalu menjadi 1,4GB. ISO instalasi 1,4GB, mesin yang baru dipasang juga 1,4GB.
      Situasi ingin membangun proyek C++ besar sudah merupakan jalur yang matang, dan mengganti C++ dengan Rust tidak mengubah esensinya. Ada sistem build yang membuat kondisi library tidak terlalu menyakitkan, dan meskipun sistem-sistem itu sama rumitnya dengan Nix, sebagian lebih cocok untuk penggunaan ini. Karena Nix mencoba menjadi sistem build untuk membangun software orang lain dan nixpkgs, ia berada di sisi yang sangat umum. Sistem build yang dirancang untuk membangun software sendiri biasanya melakukan pekerjaan itu dengan lebih baik. Secara pribadi saya puas dengan Bazel, dan selain go build untuk proyek khusus Go, saya mungkin hampir tidak akan memakai yang lain, tetapi pilihannya banyak. Dalam 99% kasus, pakailah alat semacam itu alih-alih Nix, lalu tulis flake agar orang bisa menginstal versi terbaru lewat home-manager.

  • Bagian pemilihan versi terdengar aneh. Versi di nixpkgs masuk akal saat menjalankan atau membangun sistem, tetapi jika sebagai platform ia menyediakan runtime atau compiler, diperlukan pendekatan seperti devenv yang menyediakan versi secara langsung
    Jika membangun sistem lama demi menyediakan nodejs lama, patch keamanan untuk dependensi bisa terlewat. Devenv menanganinya, misalnya dengan https://github.com/cachix/nixpkgs-python, dengan cara “menjaga semua versi Python tetap mutakhir setiap jam dengan Nix”
    Railway menyuntikkan variabel lingkungan deployment ID ke semua build sebenarnya bisa saja dilakukan di lapisan setelah instalasi. Paket juga bisa dipecah menjadi beberapa lapisan, dan ada otomatisasi berbasis bundel untuk mengurangi jumlah lapisan

  • “Masalahnya bukan pada Nix sendiri, melainkan pada cara kami menggunakannya” adalah contoh bagus dari gunakan alat yang tepat untuk pekerjaan yang tepat. Nix sangat bagus untuk sebagian kegunaan dan buruk sekali untuk kegunaan lain
    Masalahnya, kurva belajar Nix terlalu curam; pada saat sudah cukup paham untuk menilainya, orang sudah menginvestasikan terlalu banyak waktu sehingga merasa sayang untuk mundur, lalu memaksakannya agar cocok dengan kebutuhan awal

    • Aku juga merasakan hal serupa, tetapi dalam beberapa hal Nix lebih dekat dengan paradigma pemrograman umum dibanding sistem operasi lain. Kita saja belum terbiasa memikirkan sistem operasi dengan cara seperti itu. Ekspresi Nix punya input, berisi repositori paket dan banyak pasangan key-value, lalu output-nya adalah sistem Linux. Beberapa tahun lagi, ini mungkin akan terasa jauh lebih biasa
      Karena paradigma ini, AI sangat mudah membuat shell.nix atau configuration.nix yang sesuai spesifikasi. Misalnya bisa memuat paket Python, paket Linux, variabel lingkungan, entri path, dan sebagainya
      Aku sering memakai ini untuk menyertakan lingkungan yang sepenuhnya mendukung paket tersebut di repositori. Dengan flakes hasilnya akan lebih dapat direproduksi, tetapi aku memahami flake.nix sebagai semacam shell.nix dengan pinning versi, dan masih mempelajarinya

  • Sepertinya mereka berusaha memaksakan versi ke tempat yang tidak punya versi. Seperti memasukkan kubus persegi ke lubang bundar
    Katanya “versi default” merusak sesuatu yang bergantung padanya—aku tidak mengerti maksudnya. Itu seperti memakai tag :latest di Docker, lalu terkejut ketika server baru naik dengan versi yang berbeda dari image “default” sebelumnya dan semuanya rusak
    Aku sama sekali tidak memahami penjelasan di tulisan blog ini. Mereka terlihat seperti orang yang sama sekali tidak tahu apa itu “versi” perangkat lunak
    Klaim bahwa “tidak ada cara memisahkan dependensi Nix ke lapisan terpisah” juga tidak jelas alasannya. Tentu saja /nix/store bisa dibagi menjadi sebanyak mungkin lapisan yang diperlukan. Aku bahkan mempertanyakan apakah mereka tahu cara memakai container dan Nix sejak awal
    Melihat ketidakmatangan yang begitu jelas ini, tidak mengherankan kalau solusi yang mereka usulkan terasa amis. Ini sindrom NIH klasik, dan tampaknya besar kemungkinan masalah yang sama yang tidak mereka selesaikan dengan Nix akan ikut menjalar ke “solusi” baru itu

    • Aku setuju untuk tidak memakai Nix, terutama di tempat yang memang tidak masuk akal. Namun hanya dengan meluangkan beberapa jam saja orang bisa melihat bagaimana masalah-masalah itu sudah diselesaikan, jadi membangun ulang sistem yang sudah berjalan dari nol karena alasan yang sebenarnya bukan masalah terasa pada dasarnya aneh
      Seperti dikatakan orang lain, nix2container dan flakes tampaknya akan menyelesaikan semua masalah yang mereka punya
      Untuk manajemen versi, flakes yang kutulis 3 tahun lalu sampai sekarang masih dibangun dengan versi yang persis sama dan output yang persis sama seperti saat pertama ditulis
      Memang terdengar seperti mereka ingin masuk pasar sebagai platform dan menggalang investasi
      Edit: Aku baru saja mengecek GitHub nixpacks, dan langsung terlihat bahwa mereka memakai rustPlatform dari nixpkgs, bukan rust-overlay[0] milik oxalica yang pasti muncul hanya dengan pencarian sekilas soal masalah Rust. rust-overlay adalah salah satu overlay paling berguna dan kuat yang pernah kupakai
      [0] https://github.com/oxalica/rust-overlay
    • Kalau tujuannya mendapatkan pendanaan VC, platform deployment lebih laku daripada wrapper Nix

  • nix2container[1] memang bisa memisahkan dependensi ke lapisan tersendiri. Kita bisa secara eksplisit membuat lapisan yang hanya berisi sebagian dependensi yang dibutuhkan image, dan contohnya ada di bagian ini: https://github.com/nlewo/nix2container?tab=readme-ov-file#is...
    Misalnya jika image-image memakai bash, kita bisa secara eksplisit membuat lapisan yang berisi closure bash. Lapisan ini digunakan ulang oleh semua image, dan hanya dibangun ulang serta di-push ulang ketika closure bash tersebut berubah
    Klaim bahwa image menjadi besar karena satu lapisan /nix/store memang berlaku untuk fungsi default nixpkgs.dockerTools.buildImage, tetapi tidak berlaku untuk nix2container atau nixpkgs.dockerTools.streamLayeredImage. Alat-alat ini tidak menulis lapisan ke Nix store, melainkan membuat skrip yang benar-benar mem-push image dengan menggunakan path store yang sudah ada. Implementasi nix2container membuat berkas JSON yang menjelaskan path Nix store untuk semua lapisan, lalu Skopeo mengonsumsi JSON ini untuk mem-push image ke Docker daemon, registry, podman, dan sebagainya
    Sebagai catatan, aku adalah pembuat nix2container
    [1] https://github.com/nlewo/nix2container

    • Berkat nix2container, aku memakainya untuk deployment AWS ECR, dan waktu iterasi antar-build turun menjadi hitungan detik satu digit
    • Aku sedang menyempatkan waktu untuk bereksperimen dengan nix2container karena ada masalah ukuran image Docker. Terima kasih atas karyanya

  • Masalah inti di sini adalah tetap berpegang pada sikap sup versi kustom yang didorong oleh package manager bahasa. Pendekatan ini benar-benar tidak berkelanjutan
    Alternatifnya, Mise, tampaknya tidak punya kemampuan memahami batasan versi antar-paket, dan sepertinya juga tidak menjalankan pengujian untuk memastikan tiap paket yang terpasang bekerja baik dengan versi-versi di sekitarnya. Kalau begitu, yang didapat sama sekali bukan hal yang sama

  • Sup versi kustom memang tidak berkelanjutan, tetapi salah satu alasan orang terus memakainya adalah karena pada umumnya berjalan dengan baik. Salah satu alasan ia berjalan baik adalah karena library di level sistem operasi berasal dari dunia lain yang jauh lebih konservatif, dan sebisa mungkin berusaha menghindari pemutusan kompatibilitas ke belakang
    Jadi kita bisa memakai sistem operasi yang stabil dan terkelola dengan baik sebagai dasar, lalu di atasnya menumpuk sup versi kustom untuk tool dan runtime bahasa dengan alat seperti mise atau asdf, kemudian menjalankan aplikasi. Hampir tidak pernah rusak. Saat rusak, kita mengutak-atik versi dan perbaikan kecil sampai berjalan lagi, lalu lanjut. Fakta bahwa itu rusak memang menyebalkan, tetapi tidak penting. Menambah friksi, menuntut pembelajaran, atau meminta lebih banyak pekerjaan adalah buang-buang waktu
    Sebaliknya, ada juga orang yang mencari solusi agar hal itu tidak pernah rusak lagi. Bagi orang-orang ini, masalahnya penting, jadi tidak apa-apa jika solusinya menuntut friksi, pembelajaran, dan pekerjaan tambahan. Orang-orang seperti inilah yang menginginkan Nix
    Kebanyakan orang termasuk kelompok pertama, jadi perusahaan seperti Railway yang ingin tumbuh pada akhirnya akan memilih solusi yang cocok untuk kelompok itu

    • Bisa jelaskan lebih lanjut apa maksud sikap “sup versi kustom” itu dan apa alternatifnya?
    • Jika dilakukan dengan benar, kita bisa mendapatkan keduanya. Misalnya, membangun paket Rust dengan Nix dari file Cargo.lock itu hal sepele. nixpkgs memang berlawanan arah dengan sup versi kustom, tetapi Nix itu sendiri juga bisa menangani pendekatan tersebut dengan cukup baik

  • Dari pengalaman bekerja sebagai DevOps/SRE, ketika seseorang mencoba membuat sistem untuk mengelola dependensi dan semacamnya, biasanya mereka mengambil salah satu dari dua jalan. Python bisa dijadikan contoh
    Opsi 1: “Mari pakai satu repositori tunggal besar yang dibagikan.” Kelebihannya, semuanya ada di satu tempat, kebutuhan sudah tercakup, dan semua orang memakai hal yang sama sehingga masalah seperti kerentanan lebih mudah diperbaiki. Kekurangannya, selalu ada orang yang menginginkan versi khusus, rollout bertahap sulit sehingga perubahan mudah menjadi big bang, dan muncul pertanyaan “bagaimana membuat versi Docker yang kecil?”
    Opsi 2: “Semua orang punya conda/venv masing-masing.” Kelebihannya, tiap orang mendapatkan persis yang mereka inginkan, tidak memakai paket yang tidak dibutuhkan, dan upgrade bertahap lebih mudah. Kekurangannya, muncul pertanyaan “sebenarnya ada berapa banyak environment conda?”, library dari kelompok berbeda mungkin tidak pernah diuji dengan kombinasi library Python yang sama, dan karena kita bahkan tidak tahu di mana saja environment conda yang berbeda berada, manajemen kerentanan menjadi mimpi buruk
    Jadi saya selalu skeptis terhadap klaim “cara baru ini menyelesaikan semuanya”. Semakin panjang karier, kalimat “tidak ada solusi, yang ada hanya trade-off” terasa semakin benar

  • Bahkan dari sudut pandang seseorang yang hanya punya sedikit pengalaman dengan Nix, poin-poin di sini tidak terlihat terlalu tepat
    Ada pernyataan seperti “tidak jelas atau tidak mudah dipelihara bagi kontributor yang tidak terbiasa dengan manajemen versi Nix” dan “Node serta Python akhirnya hanya mendukung versi mayor terbaru”, tetapi saya tidak mengerti mengapa itu tidak bisa dipelihara. Jika alasannya karena harus membuat daftar versi yang tersedia, saya bertanya-tanya apakah itu tidak bisa diotomatisasi
    Lebih jauh lagi, saya juga tidak mengerti mengapa Railway mendefinisikan cara pengguna memakai Nix. Bukankah salah satu inti Nix adalah bisa mengonfigurasi mesin kosong dengan versi paket persis yang diinginkan? Saya tidak mengerti mengapa Railway harus berada di antara pengguna dan versi itu lalu membatasinya
    Jika strukturnya memang membuat pengguna tidak melihat Nix secara langsung, pertanyaan awal tetap tersisa. Apakah daftar versi paket tidak bisa diotomatisasi?

    • Batasan versi berasal dari fakta bahwa cache Nix tidak mempertahankan versi lama. Jadi jika memakai versi lama, harus mengompilasi dari source. Terdengar seperti mereka tidak ingin menyediakan cache sendiri untuk versi lama, meski rasanya itu bukan upaya yang sangat besar
      Sejujurnya, alasan-alasan yang disajikan tidak terlihat terlalu kuat. Mungkin orang yang memperkenalkan Nix sudah pergi, dan orang-orang yang tersisa tidak terlalu menyukainya. Bahasanya sendiri memang tidak terlalu bagus, dan dokumentasi lamanya juga tidak hebat
      Meski begitu, saya tidak cukup mengenal stack yang mereka pilih, tetapi saya penasaran apakah stack itu menyediakan tingkat determinisme yang mendekati Nix. Jika tidak, hal itu bisa menjegal mereka nanti atau membuat operasi lebih sulit
    • Di tulisan itu ada pernyataan bahwa “cara Nixpacks menarik dependensi berujung pada image raksasa dengan satu lapisan /nix/store, yang berisi semua paket dan library terkait Nix yang dibutuhkan saat build dan runtime”
      Pernyataan ini mirip seperti “kami menyerah pada mobil karena tidak bisa membuat mobil maju”. Ini salah satu hal yang paling andal dilakukan Nix. Ia secara otomatis mendeteksi dependensi runtime yang benar-benar direferensikan dari binary hasil build lewat pencocokan string hash /nix/store
      Jika mereka sampai tidak bisa melakukannya, berarti mereka memakainya dengan cara yang cukup aneh atau melakukan kesalahan serius. Sampai-sampai sulit membayangkan bagaimana caranya mencegah Nix menyelesaikan ini secara otomatis
      Jadi saya tidak akan menerima pengalaman Nix mereka terlalu mentah-mentah. Bagian tentang manajemen versi adalah masalah yang sangat umum dialami semua orang, jadi akan lebih menarik jika mereka mencoba menyelesaikannya
    • Pemahaman bahwa strukturnya membuat pengguna tidak melihat Nix secara langsung setidaknya sama dengan pemahaman saya
    • Walau proyek sama sekali tidak memiliki Dockerfile, jika Anda push kode ke Railway, mereka akan membangun image dengan Nixpacks. Log build mungkin menampilkan hal-hal terkait Nix, tetapi sebagian besar berjalan di balik layar

  • Nix tidak memberikan jaminan versi arbitrer, melainkan jaminan commit. Jika muncul edge case, mereka akan kesulitan karena perubahan glibc atau library bersama yang bentrok
    Mungkin agak terlambat, tetapi saya dengan senang hati bisa menawarkan konsultasi untuk membuatnya berjalan dengan cara idiomatis Nix. Produknya terlihat keren

    • Nix menyelesaikan masalah inkompatibilitas library bersama dengan cara yang sangat konservatif. Jika apa pun berubah—baik perubahan bermakna maupun tidak—bahkan hanya perbaikan komentar, perubahan dokumentasi, atau penambahan test case, semua dependensi akan dibangun ulang
      Bukan hanya itu, dependensi dari dependensi, lalu dependensi dari dependensi tersebut, dan seterusnya juga ikut berlanjut, sehingga rebuild berskala besar sering terjadi
      Bentrokan library bersama memang akan dihindari, tetapi solusi ini sangat boros dan juga bisa membuat pengembangan menyakitkan. Itu bisa terlihat dari proses staging di nixpkgs
    • Saya sepenuhnya memahami value proposition Nix. Namun menurut saya ungkapan “akan kesulitan” agak berlebihan. Paling jauh, itu berarti “kehilangan jaminan yang cukup penting dibandingkan Nix”
      Meski begitu, sepertinya hasilnya tetap akan “dikemas dengan kemungkinan berjalan normal yang lebih tinggi” dibandingkan 95% software di dunia

  • Saya tidak mengerti mengapa mereka tidak bisa membuat derivation sendiri alih-alih bergantung pada hash nixpkgs