probonopd / go-appimage

Go implementation of AppImage tools
MIT License
680 stars 69 forks source link

Added support for watchfolders.conf #213

Closed trumpton closed 1 year ago

trumpton commented 2 years ago

Added search for ~/config/appimaged/watchfolders.conf and /etc/appimaged/watchfolders.conf (in that order).

If present, the folders identified in the watchfolders.conf are used in preference to the hard coded candidateDirectories list.

The watchfolders.conf file expects to have a list of folders in it (one per line). Lines starting with # are ignored ~/ is parsed and replaced with /

probonopd commented 2 years ago

Hello @trumpton I appreciate your contribution but I will probably not merge it since appimaged is designed to be configuration-free and shall work the same way for everyone. Can you imagine any automatic mechansim to "guesstimate" the directories, that would give you a similar result?

trumpton commented 2 years ago

Understand the concept ... I've got applications installed under the /opt tree

Specifically, I have /opt/bin which contains soft links to the appropriate executables these are normally linked to /opt//bin/

However with AppImages, there is not normally any need for an /opt//bin hierarchy as all essential files are bundled with the AppImage. In these cases I have a soft link from /opt/bin/appname to /opt/appimages/appname.AppImage

i.e. I would never place executable files directly into /opt

Could the appimaged program:

  1. Use the user's PATH to identify places to search
  2. If a soft link is found, follow it and check if the target file is named *.AppImage
  3. Install the application/icon to point to the soft link, rather than the executable

Or

  1. change the search in /opt to /opt/bin
  2. Follow soft links to check file is an AppImage before adding the soft link
  3. Install the application/icon to point to the soft link, rather than the executable

The second and third point allow new AppImages to be installed, and a soft-link modified to point to the latest / desired version, much in the same way that /bin/clang and /bin/clang-14 both point to the same executable; and should there be an update to clang-15, /bin/clang-14 would still remain, but /bin/clang would be udpated.

See: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html

probonopd commented 2 years ago

How about adding /opt/bin in addition to /opt? Would that already address a large part of your concern?

Regarding points 2 and 3 I am not sure. Personally I don't like using symlinks to determine which version of something gets used (e.g., you can never know what python points to...). I'd much rather have all versions integrated, and choose. Personally I am using ~/Applications and ~/OldApplications; I move the ones I want integrated into the former and other verions into the latter.

snowyu commented 1 year ago

I've many binary files in /usr/local/bin, but no any appimage file. So It may be crazy to scan such directory.

probonopd commented 1 year ago

Open to suggestions that do not require the user to configure something.