Add AppMan AppImage (AM)

[zen0bit]

Should be done like first app...

And I already said my thoughts about am/appman...

[zen0bit]

So bundled with all dependencies and released as *.AppImage

[Samueru-sama]

AppImages are for portable apps but AM and AppMan are not really portable as they need to be on a certain location and their modules need updating.

So the appimage would be just an installer and shortcut for am/appman at most.

With that said, a one click installer would be great, pkexec can be used in the case of AM as it needs root permission to install.

Also both am/appman need very little dependencies, like bash, core utils, wget, zsync and thats about it. Because even xdg-user-dirs is now optional (the readme hasnt been updated about that)

[zen0bit]

wget zsync

[ivan-hc]

@zen0bit this is a movie I've already seen... and done. I don't remember if it was a 2.x or 3.x release.... but an AppImage of AppMan has already be done. So if I refuse to bundle it today (and expecially today, with all these PR with/without issues) there is a reason. To be a script is better, it is always updatable and without critical bugs because of this. Having system dependences is not a problem at this point. If you're afraid about the total replacemente of "wget" for "wget2", we can always find a solution. The other day, @Samueru-sama has uploaded the portable version of "gum", why we can't do the same with "wget" and something else? All will change will be the INSTALL script for "AM", while AppMan is already portable. "zsync" instead is an optional dependence, and the installation process will advice you if it is needed, and like we have done with "gum", we can do the same with "zsync", I did the same with "libfuse2", also installable using AM/AppMan.

[ivan-hc]

Questions?

[zen0bit]

Questions?

👍
But why we can have it? And work nicely?

it is always updatable and without critical bugs because of this

And in AppImage not? I thought that exactly this AM do no?

• If Appimage needs to contain your am + zsync + wget what else needs to be there?
• In this point could be just dir with am + deps + .desktop file hidden in am.AppImage "directory" file which will trigger am inside?
• But as in AppMan installation path is choose able same should be done for am on build/install (like makefile = template with instructions for instalation) level

Whats criterium from calling app AppImage except extension?

[ivan-hc]

👍 But why we can have it? And work nicely?

because its useless, I've already created it in the past. This is included in my answer above.

it is always updatable and without critical bugs because of this

And in AppImage not? I thouth that exactly this AM do no?

AppImages are more difficult to be updated in real time, while scripts are more dinamic and flexible to manage... for example, if someone decided to remove the ".am" extensions from the main CLI because wanted to made AM look better, and without thinking that, maybe, they are there for some reasons (maybe a random module... clean.am, needs to have a list of modules not to be removed so it searches the keywords in there.... ), that asshole of the upstream developer cannot patch it in real time if it is an AppImage. However, the contributor does not care about it, him only want to made the CLI more beautifize.

PS: Any reference is purely coincidental, no animals were mistreated during the writing of this answer... especially crickets, like the one some developers use as avatars.

[zen0bit]

PS: Any reference is purely coincidental, no animals were mistreated during the writing of this answer... especially crickets, like the one some developers use as avatars.

Not developer (Leave my crickets)

Whats criterium from calling app AppImage except extension?

PS: Maybe i can start calling myself like that
You are second one who call me like that. First one was lazygit on first open
Great App BTW https://github.com/jesseduffield/lazygit (Can't imagine work with git withou it)

[ivan-hc]

Create the appdir, place the script, bundle as an appimage, wait the GH action.... its a waste of seconds/minutes! And because of someone I wont name, I know well that these minutes are strictly important to prevent bugs and issues un the PC of other people around the world using this app. But the fault is not of the contributor, its mine, and I wont to have panic because I have to bundle the AppImage always and always and always due to someone.

[ivan-hc]

Found, it was AppMan 4.0 https://github.com/ivan-hc/AppMan/releases/tag/4.0.0

However, its useless to use it now, please don't do it.

[ivan-hc]

I close this as not planned. I'm sure this time.

[Samueru-sama]

Hey I can add wget to the list of packages, but how do we wget wget 🤔🤔🤔

[zen0bit]

Question is:
How we can get wget without wget

[ivan-hc]

The question is... you two do too many questions: why?

[Samueru-sama]

The question is... you two do too many questions: why?

Hey I know you didn't want this, but I made a working AppMan appimage that builds and bundles wget and zsync and it works! do you want me to PR it (I can also setup the github workflow for it).

[ivan-hc]

Nope

[ivan-hc]

I don't say that its difficult to bundle. On the contrary, it is really easy. Only I don't want to maintain it. It is a CLI continuosly in evolution, with PRs, feature requests and bug fixes. Its a waste of time and a mess.

Also, AppMan is auto-updatable and the download link redirects to the APP-MANAGER script... it will be continuosly replaced, again and again... so its useless to create the AppImage of it.

Also, imagine you want to install it with AM, how could it be updated if installed in a RO $PATH?

We should not talk about this anymore. My english is not perfect, but I've not wrote in arabian or japanese, for example. I think we all talk in english here, nope?

I confirm my choice, if you want to maintain an AppImage of it, do it by yourself... but its useless and insecure.

I've talked.

[Samueru-sama]

Too late: https://github.com/Samueru-sama/AppMan-AppImage

@zen0bit I also bundled gum and your apptui PR. Give it a test.

To launch the TUI you need to pass the --TUI flag when launching the appimage.

I confirm my choice, if you want to maintain an AppImage of it, do it by yourself... but its useless and insecure.

It's ok, I'm doing this to experiment.

I guess I can add a function that compares the version of the appimage when the github release and warns that it is out of date.

Which btw Ivan, I think we neeed to add some automatic warning that appman/am is outdated, because I have already seen 2 people that had very outdated versions of AM/AppMan and didn't notice. One was even a full year behind on updates lol.

[ivan-hc]

I guess I can add a function that compares the version of the appimage when the github release and warns that it is out of date.

and this is useless, you will see in the future

Which btw Ivan, I think we neeed to add some automatic warning that appman/am is outdated, because I have already seen 2 people that had very outdated versions of AM/AppMan and didn't notice. One was even a full year behind on updates lol.

this is a big issue, I've thinked the same... but how we can tell this to people that are using obsolete things?

[Samueru-sama]

this is a big issue, I've thinked the same... but how we can tell this to people that are using obsolete things?

We can't, but you can add a simple check when installing a program with am -i that runs am -v and a function that compares the output of am -v to the current version here and if they don't match a warning is given.

This way hopefully in the future cases of people running 1yo versions stop.

And for the present, you can simply update the issue template here to require people to post their AM version by running am -v and make it a required field.