cli binary release

[fbuchlak]

Mozno out of scope pre projekt (a mozno existuje aj ina moznost, o ktorej neviem), ale nebolo by na zvazenie spravit binary release pre cli?

Riesim paybysquare v php projekte, chcel by som sa vyhnut tomu aby som tam mal nejaky js runtime. Pozrel som ine riesenia priamo pre php, ale nie je to ziadne terno (vacsinou vyzaduju nejaku inu binarku napr. xz utils). Dalsi problem pre mna je, ze su pravdepodobne malo pouzivane a teda "neotestovane" (s tymto projektom mam skusenost na js projekte a uplne vyhovuje)

Cez bun by sa dali vytvorit standalone binarky (sice maju linknute nejake kniznice, ale tie su povacsine standard (aspon ked som si porovnal ine projekty)). Vid. https://bun.com/docs/bundler/executables Toto by mohlo otvorit cestu do inych ekosystemov.

V php svete mame napr. https://github.com/Kocal/BiomeJsBundle ktory sluzi len na stiahnutie binarky od biome (je to sice rust, ale ma podobne dynamicky linknute libs), nasledne viem tuto binarku volat z php ako subprocess. Pre bysquare by sa dalo urobit nieco podobne, stiahnutie binarky z releasov a vytvorit nejake php api na obsluhu. Samozrejme nie je to bullet proof, system potrebuje mat dostupne napr.

ldd dist/bysquare-bun-x64-linux
        linux-vdso.so.1 (0x00007ff5d0703000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff5d0517000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff5d0705000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff5d0512000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff5d050d000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff5d042d000)

ale ked to porovnam s biome

> ldd biome-linux-x64
ldd: warning: you do not have execution permission for `./biome-linux-x64'
        linux-vdso.so.1 (0x00007f15d8966000)
        libgcc_s.so.1 => /nix/store/f6famnry0piih1d3hh6y73fxx05jxsa8-xgcc-14.3.0-libgcc/lib/libgcc_s.so.1 (0x00007f15d8930000)
        libpthread.so.0 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libpthread.so.0 (0x00007f15d892b000)
        libm.so.6 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libm.so.6 (0x00007f15d8843000)
        libdl.so.2 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libdl.so.2 (0x00007f15d883e000)
        libc.so.6 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libc.so.6 (0x00007f15d5a00000)
        /lib64/ld-linux-x86-64.so.2 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib64/ld-linux-x86-64.so.2 (0x00007f15d8968000)

alebo tailwind cli (vyuzivam aj na produckii na build assetov, existuje podobny bundle ako pre biome (ten spusta subprocess v php))

> ldd tailwindcss-linux-x64
ldd: warning: you do not have execution permission for `./tailwindcss-linux-x64'
        linux-vdso.so.1 (0x00007f1201a87000)
        libc.so.6 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libc.so.6 (0x00007f1201800000)
        /lib64/ld-linux-x86-64.so.2 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib64/ld-linux-x86-64.so.2 (0x00007f1201a89000)
        libpthread.so.0 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libpthread.so.0 (0x00007f1201a7a000)
        libdl.so.2 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libdl.so.2 (0x00007f1201a75000)
        libm.so.6 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libm.so.6 (0x00007f1201718000)

tak sme viacmenej na tom istom a viem si v pohode predstavit aj vyuzitie v produkcnom prostredi v php projekte, resp. kdekolvek (bez js runtime, stacia tieto libs)

Taky mensi PoC

#!/usr/bin/env bash

# init.sh

set -e

mkdir -p bysquare-bin
cd bysquare-bin
bun add bysquare

targets=(
    "bun-darwin-arm64"
    "bun-darwin-x64"
    "bun-linux-arm64"
    "bun-linux-arm64-musl"
    "bun-linux-x64"
    "bun-linux-x64-musl"
    # "bun-windows-arm64" # not supported
    "bun-windows-x64"
    "bun-windows-x64-baseline"
    "bun-windows-x64-modern"
    "bun-x64-linux"
    "bun-x64-linux-arm64"
    "bun-x64-linux-baseline"
    "bun-x64-linux-modern"
)

for target in "${targets[@]}"; do
    output="dist/bysquare-${target}"
    [[ $target == *windows ]] && output="${output}.exe"
    echo -e "\nbuilding target $target"
    bun build \
        --compile --minify --sourcemap --bytecode \
        --target "$target" node_modules/bysquare/lib/cli.js --outfile "$output"
    echo "ldd $output"
    ldd "$output" 2>/dev/null || echo "$output: not a dynamic executable, skipped"
done

docker run --rm -it \
    -v "$PWD":/app \
    -w /app \
    oven/bun \
    bash -c "chmod +x ./init.sh && ./init.sh"

Vyslednu binarku viem spustit v inom containeri, v ktorom nie je ani bun, ani ziadny js runtime. Samozrejme toto vsetko si viem spravit "per project", ale mozno to pomoze aj niekomu inemu.

[xseman]

Neviem akú máš architektúru aplikácie, no vieš použiť libku aj priamo na klientovi, ušetrí ti to túto abstrakciu. Skús opísať akú maš sekvenciu logiky.

Ten PoC sa mi páči, s bunom sa trochu hrám a viem, že dokáže spraviť binárku. Nechcem ale publishovať 90MB+ CLI vec. Primárny cieľ libky je aby bola isomorfná, a to je už hotové. Ak by som niekedy chcel pridať binárku, spravil by som to radšej v nástroji na to vhodnejšom.. napr. C alebo Rust, Zig čo by nebolo take komplikované kedže hlavnú logiku by som prebral.

[fbuchlak]

Tu sa chcem prave vyhnut tomu aby to bezalo na klientovi. Chcel by som generovat qr kod na backende, nasledne bude generovane pdf (cez php) do ktoreho potrebujem dostat napr. qr kod v png/jpeg. Da sa to spravit rozne, mozem si vytvorit aj nejaky dalsi service, ktory budem volat a budem to mat oddelene, popripade si urobim build step, ktory mi to vytvori na zaciatku a dalej si to uz viem spustit.

Ked som sa pozrel po nejakych issues v inych repozitaroch v minulosti, tak vacsinou mali ludia problem s tym, ze tam boli dependencies, ktore na systeme byt nemuseli (tomu by sme sa uplne nevyhli ani tu, kedze to nie je staticke).

S tou velkostou mas pravdu, zbytocne tam su desiatky MB bun runtime-u a mozno budem jediny kto to takto vyuzije. Bolo by to vhodnejsie tak ako pises, toto mi vsak prislo ako take jednoduche riesenie bez nejakeho dalsieho programovania. Najprv som zvazoval podobnu alternativu (prepisat to do niecoho ineho), ale momentalne na to nemam kapacitu.

Kludne to mozme uzatvorit, ak by niekto hladal riesenie v inom jazyku a narazi na tuto issue tak z popisu by malo byt jasne ako sa to da urobit (aj ked je to asi overengineering)
Mozno v buducnosti spravim nejaku kniznicu pre php, v ktorej bude mozne nadefinovat executable (cize kazdy si tam moze dat co potrebuje, napr. spustit toto cli aj cez node/bun) - to by ciastocne riesilo problem v php ekosysteme. Ak by sa ludia chceli vyhnut tomu aby mali niekde navyse js runtime, tak si to budu vediet zbuildovat jednoducho cez bun a nastavit zbuildovanu binary.

[xseman]

A nechcel by si urobiť implementáciu v PHP? Aktuálne čo je v tomto repe je 95% hotová špecifikácia a s Claude to máš preklopené podľa tohto za víkend, teda ak nájdeš dependencie na kompresiu v PHP.

Možno by nebolo zlé urobiť cli binárku pre usecase podobné tvojmu, kde by si očakával publishnuty artefakt?

[fbuchlak]

Naposledy ked som to pozeral, tak som prave nenasiel dependencies na kompresiu pre PHP (existuju aj nejake extensions, ale nic z toho nie je standardne (navyse to co som nasiel podporuje iba lzma2, tu ak sa nepletiem sa pouziva lzma1)). Kvoli tomu aktualne riesenia vyzaduju xz binary (vid. napr. https://github.com/RikudouSage/QrPaymentSK). Mozno ale zbytocne spekulujem a dotiahnem si tam len xz. V oboch pripadoch potrebujem spustat dalsi proces, takze je to viacmenej jedno.

Ak by si sa predsalen rozhodol spravit binarku, tak za mna staci publish na github cez releases. Kvoli mne to ale zatial netreba robit, mozno keby sa tu nazbieralo viac ludi, ktori potrebuju nieco podobne, tak by to mozno stalo za zvazenie.

Ak by som si na to nasiel nejaky cas a bolo by nutne nieco programovat navyse, tak by som sa vratil skor k tomuto navrhu (to by malo asi vacsi prinos ako kniznica len pre php; z tohto by sa dalo relativne jednoducho poriesit aj nejake FFI, ktore uz podporuje aj samotne php (priklad podobnej implementacie je libvips + php-vips)).

Ak by som niekedy chcel pridať binárku, spravil by som to radšej v nástroji na to vhodnejšom.. napr. C alebo Rust, Zig čo by nebolo take komplikované kedže hlavnú logiku by som prebral.