Appimagekit: [appimaged] Allow overriding monitored directories.

[Celti]

Sometimes you want to store AppImages in different directories, or ignore AppImages in the default hard-coded directories. I suggest using an environment variable, perhaps APPIMAGE_PATH, with multiple directories separated by colons (as per the standard PATH environment variable).

[TheAssassin]

Some kind of feature like this is requested periodically. @probonopd once stated that the more configuration possibilities there are, the higher the potential for misconfiguration is. Hence, we won't introduce such a feature, neither per configuration file nor per environment variable. Closing as wontfix.

If you have additional directories appimaged should be searching for AppImages in, however, we will consider adding them in the code.

[probonopd]

@Celti please state which directories you would like to see added and we will see if this could be something that many users might be interested in. The AppImage philosophy is that things should "just work" without configuration.

[Celti]

The problem being that some things require configuration. Nobody can predict and support every possible use-case out of the box.

I don't personally care too much about adding specific directories (though I would use the feature if available); what I actually want is for $XDG_DOWNLOAD_DIR to not be monitored — which of course not monitoring that definitely goes against the idea of "it just works" for plenty of users that aren't me.

I can, of course, write my own tool for this instead (and probably will, at this point).

[probonopd]

I can, of course, write my own tool for this instead (and probably will, at this point).

Not needed, just fork this repo and change the code around here.

https://github.com/AppImage/AppImageKit/blob/0c9504f0372257ba0df7b700392c49a65263fc38/src/appimaged.c#L321-L333

[TheAssassin]

I can, of course, write my own tool for this instead (and probably will, at this point).

I don't really understand why people think they need to invent their own tools, instead of "fixing" the problematic ones in the source code. In this case, it's pretty easy, actually, as @probonopd showed.

[simoniz0r]

I don't really understand why people think they need to invent their own tools, instead of "fixing" the problematic ones in the source code.

I think that mostly comes from the PRs welcome mentality for issues that would be pretty easy to solve on the developer's end. Makes the users feel like their issues don't really matter to the dev.

[KurtPfeifle]

@probono said:

"The AppImage philosophy is that things should "just work" without configuration."

This does NOT exclude that you could make available some configuration abilities for those more advanced users who know how to make use of it. If no explicit configuration is present, use the built-in defaults which should "just work", yes.