Jak najprościej udostępnić użytkownikowi aplikację konsolową?

Pytanie z tytułu tego wątku może wydać się niezrozumiałe, ale dobrze oddaje stan mojego rozumienia tematu. Najlepiej wytłumaczę na przykładzie.

Jak może niektórzy kojarzą, stworzyłem prostą aplikację JavaScript + Bash. Pisałem o niej na forum tym wątku. Na razie jedyny UI tej aplikacji to CLI, planuję dorobić GUI. Mam zamiar też zrobić jakiś interfejs łatwy do użycia przez internet (jeszcze nie wiem co). Na razie docelową platformą jest Linux na desktopy; później może Windows, a jak się uda, to i coś mobilnego oraz Mac.

Obecnie udostępniam jedynie źródła aplikacji na GitHubie, tzn. "pliki z kodem". Proces uruchamiania aplikacji wygląda tak: przejdź do głównego folderu aplikacji, wpisz odpowiednią ścieżkę do pliku wykonywalnego (ustawiłem chmod u+x), podaj parametry, ENTER. Nie ma żadnej kompilacji czy budowania. Niestety, to nie zadziała, jeśli ktoś nie ma zainstalowanego Node.js i Basha.

Domniemywam, że dla zwykłego użytkownika (nie-dewelopera) taki proces będzie problemem. Nie będzie chciało mu się przechodzić do odpowiedniego katalogu (nawet stosując kopiuj-wklej z README). Nie będzie on chciał sprawdzać, czy ma zainstalowane coś-tam przed uruchomieniem. Najpewniej będzie mieć Basha, ale bardzo wątpliwe, że Node.js.

Domniemywam, że da się tę aplikację – i każdą inną, podobną – udostępnić mu w łatwiejszy sposób (na razie tylko na Linuksie, jak napisałem). Przykładowo: – "kliknij dwa razy na ten plik". Albo – "wykonaj ten a ten plik w konsoli". Interesuje mnie zarówno proces uruchamiania po instalacji (choć czymże jest instalacja? Czy nie jedynie kopiowaniem plików i ustawieniem PATH?), jak i proces uruchamiania bez instalacji. Żeby zadziałało bez przechodzenia do konkretnej ścieżki – z każdego katalogu. Bez zastanawiania się, czy coś jest zainstalowane – oprogramowanie samo zapyta lub przerwie proces, lub... zrobi coś innego (sam nie wiem, co byłoby najlepsze).

Nie wiem zresztą, które z powyższych założeń mają sens w świecie Linuksa. Spotkałem się z tyloma różnymi opiniami w internecie dot. tych zagadnień, że czasem sobie myślę, że aż strach coś wypuszczać – u co najmniej jednej trzeciej potencjalnych użytkowników nie będzie kompatybilnej wersji czegoś-tam...

Jak osiągnąć to, co opisałem? Odpowiedź nie musi być krótka i treściwa; interesują mnie wszelkie rozważania na ten temat, chcę go zrozumieć.

UPDATE:

Pisząc powyższe, ułożyłem sobie moje wątpliwości trochę w głowie ( ;) ), ale jeszcze dużo zostało do wyjaśnienia.

W internecie można znaleźć pojęcie automatyzacji. Nie chciałbym kierować odpowiedzi w jedną stronę (o ile jakieś w ogóle będą) – jestem otwarty na propozycje zarówno ze świata JavaScript – npm, ze świata Linuksa – makefile, jak też z każdego innego. Nie chodzi mi o samo narzędzie; ważne też jest to, co ono robi i tworzy (tworzy plik binarny? zip? inny? kopiuje? modyfikuje? sprawdza zainstalowane oprogramowanie?).

UPDATE2: Główne pytanie dotyczy aplikacji konsolowej, ale chętnie posłucham też, jeśli ktoś będzie mieć przy okazji jakieś rady na temat udostępniania aplikacji przez internet, mobilnie czy okienkowych.

UPDATE3: Choć może nie napisałem tego wyżej wyraźnie, to interesuje mnie także taki proces dla dewelopera. Zazwyczaj obrazuję go sobie w głowie za pomocą zdania: "przejdź do głównego katalogu projektu, wykonaj make build i działa". Ale to zbyt ogólne stwierdzenie, by móc coś z nim zrobić. Co działa? (Plik?) Gdzie działa? (Przecież nie "wszędzie").

Możesz:

1 Użyć GNU Autotools - toole do generowania skryptów configure oraz makefile z targetem make install uinstall. Toole te są bardziej do C i ładnie generują skrypty ale może uda się do js to zrobić a na pewno można ręcznie je napisać. Configure sprawdza czy są zależności (np node) i jak nie ma to user musi dociągnąć, make buduje, make install kopiuje binarki j ustawia path i inne a uinstall wywala program. Jest to koncepcja znana z świata uniksa gdzie paczka musi mieć standardowe katalogi, podręcznik Man dla programu etc.

2 Przygotuj paczki dev, rpm etc. Lub inne do innych distro jak do PackMana z archa czy merge z Gentoo. Paczka ma Twoja bibarke/skrypt i potrafi sama dociągnąć zależności.

3 Użycie flatpacka - troszkę jak paczki ale zawiera wszystkie zależności.

4 Skrypt bash - coś Ala rozwiązanie 1 ale musisz sam opracować strukturę skryptów, dociąganie zależności, interakcje z userem etc. Mniej sztywne ale tez popularne.

W zasadzie to spotykałem się z tymi 4 typami głównie. Raz czy dwa dostałem program instalujący Ala instalator z Windows ale to baaardzo rzadko i zazwyczaj coś nie działa i jest problem - skrypty instalacyjne poprawisz, a paczki pod distro same ogarniają zależności a tutaj jak zrobisz błąd lub na jakimś distro nie działa to kaplica.

Głównie tych mechanizmów na Unixach używam. Jest jeszcze pip i npm i to są managery pakietów dla python czy js ale noe znam ich a i nie wiem czy user powinien mieć takie toole jak chce tylko używać programu i to w cli.

@somedev, dzięki za wypisanie możliwości. :) W zasadzie to połowa sukcesu, bo jeszcze chciałbym zrozumieć, dlaczego poszczególne rozwiązania w ogóle zasługują na rozpatrywanie ich (plusy i minusy, ale tak w stronę porównania jednego z drugim).

Wypiszę dalsze pytania, jakie mi przyszły do głowy po przemyśleniu. Załóżmy, że mówimy o mojej aplikacji (logika w JS, interfejs CLI w Bashu):

1. Dlaczego jest tyle możliwości? :|
2. Czy możliwe jest uruchomienie programu zarówno bez instalacji, jak z i instalacją? Plusy i minusy?
3. Dlaczego miałbym przygotować paczkę, np. rpm? Rozumiem, że potem mogę ją zainstalować np. poleceniem dnf install XYZ.rpm, ale czy to jest jedyny plus (łatwość i spójność instalacji) i nie ma minusów? Czy wrzucenie paczki do jakiegoś repozytorium jakiejś dystrybucji Linuksa to jest takie hop-siup, czy może powinna ona spełniać jakieś kryteria – na przykład użyteczności?
4. Co to jest plik binarny? Nie chodzi mi o to, co jest w pliku binarnym – o tym mogę poczytać i już to zrobiłem w części – tylko co się kryje pod tą nazwą w świecie Linuksa? — Czym różni się od skryptu? Dlaczego się używa takich plików zamiast plików o innych formatach?

3 Użycie flatpacka - troszkę jak paczki ale zawiera wszystkie zależności.

Hm, o tym jeszcze poczytam.

Pogram w Node.js możesz spakować w binarkę razem z zależnościami na każdy popularny OS za pomocą pkg.
Potem zwykle wystarczy dodać symlinka do /usr/bin - możesz to zawrzeć nawet w samym programie jako komendę odplaną z sudo.
Jak chcesz to dystrybuować przez linuksowe package managery no to już musisz wylukać instrukcje per manager.

Dla użytkowników którzy mają node'a i npm lepszą (lżejszą) opcją jest instalowanie z npm.
Wystarczy dodać do package.json pole wskazujące na plik wykonywalny (root aplikacji), np."bin": "src/cli.js",
Plik wykonywalny powinien zaczynać się od shebanga, dla plików js będzie to #!/usr/bin/env node

Taką paczkę npm można zainstalować globalnie: npm i your-package -g i wtedy będzie dostępna zewsząd.
Ba, nie trzeba nawet instalować jak rzadko używasz, możesz odpalić przez npx (instalowany automatycznie razem z npm od bodajże wersji 5.2.0) : npx your-package [...arguments]

Stworzyłem nową issue, by uporządkować część spraw: https://github.com/silvuss/silvuss-bracket-string-validator/issues/41. W miarę myślenia nad nimi będę pisać w tym temacie.

@Maciej Cąderek, @somedev – być może będę potrzebować Waszej porady jeszcze ;), ale muszę sobie ułożyć to w głowie na razie.

Co do samej CLI - nie znam się, więc się nie wypowiem.

Co do udostępnienia jako aplikacji natywnej z UI - na linuxie nie wiem. Na Windowsa - zrób instalator :P. Na Androida - google Play. Na Ios - sklep.
Jak widać każda z tych opcji to sporo wysiłku.

Jeśli interesuje Cię interfejs mobilny i hostowanie (możesz nie chcieć płacić za to) to no cóż, stwórz interfejs webowy, stronkę, która to będzie realizować. Wtedy każdy będzie miał dostęp przez przeglądarkę. Ale to oczywiście oznacza UI. I mnie wydaje się to najbardziej sensowną opcją dla "nie-cli". Robisz jeden UI który działa tak samo wszędzie. I nie trzeba nic instalować.
Można zrobić krok naprzód do tego i PWA, które na telefonie się "zainstaluje" jak aplikacja. Można wtedy też zdaje się ją wrzucić do sklepów, jeśli byś chciał.