probonopd / go-appimage

Go implementation of AppImage tools
MIT License
821 stars 71 forks source link

[Idea] Automatically integrate into ~/bin #172

Closed almereyda closed 3 years ago

almereyda commented 3 years ago

The developer of wezterm makes a good suggestion in the installation manual of the tool:

https://wezfurlong.org/wezterm/install/linux.html

That said, you may wish to make it a bit more convenient:

mkdir ~/bin
mv ./WezTerm-20210814-124438-54e29167-Ubuntu16.04.AppImage ~/bin/wezterm
~/bin/wezterm

After integrating an AppImage to the system, it's path and name are deterministically prescribed, why maintaining an ~/.local/appimaged/bin mirror of symlinks to the managed, self-contained binaries, with adding them to PATH may render the integration even more thorough, and e.g allow calling AppImages from scripts (respecting PATH) or allow invoking command line tools and fitting them into pipelines more easy.

A special case to consider would be the presence of AppImages trying to register the same binary/-ies. Then preference should be given to the highest version automatically.

Is there a way in the AppImage manifest to describe such binary/-ies, similar to npm run scripts?

probonopd commented 3 years ago

Maybe a bit dangerous? I can imagine situations in which this might lead to, well, unexpected results.

almereyda commented 3 years ago

Let's identify the edge cases in advance and conceptually work around the expected errors: What could possibly go wrong?

probonopd commented 3 years ago

A random application might claim that it wants to be sh.

Two AppImages might claim that they want to be the same command name.

Users would have no obvious way of knowing which AppImage is reachable under what command name.

The more I think about it, the more I think is that it is better if users explicitly create symlinks if they so desire.