[FEATURE] Relative imports

[max-ishere]

Implemented in #986

I want to add relative imports to Yuck, but I am not sure about how they would work exactly.

The usecase is simple. You want to import someone else's bar. So you go git clone their bar into your .config/eww/. But the issue is that maybe you don't want their file structure (along side all the other widgets you already stole and will import) to take over your .config/eww/. So you place the files into deps/bar/. But now all the imports are broken because they are absolute (or relative to .config/eww/ at least).

So here's my issue: Currently all these work:

(include "file.yuck")
(include "/file.yuck")
(include "./file.yuck")
(include "../file.yuck")

And while ./ and ../ are quite obvious I am not sure what file and /file should do.

I think it is reasonable to restrict the user to their eww config dir. This means that /file.yuck would resolve to .config/eww/file.yuck, instead of <root of filesystem>/file.yuck.

However I can see how some might say that file.yuck should be relative and some may say that is absolute.

So I want to hear some more feedback on this feature.

TL;DR:

Relative imports should work this way:

• file.yuck: Either relative or absolute, can't decide which one.
• /file.yuck: Relative to the yuck config directory.
• ./file.yuck: Just like the shell (relative).
• ../: Just like the shell (relative).

[max-ishere]

I just realized that images could be relative paths too and that changes how I want to approach this entire thing quite a bit. Mainly the /file might have to be changed to be considered an absolute (shell like) path and file a path relative to config root.

[max-ishere]

Here's another issue: While implementing #986 I was trying to fix a stack overflow that is caused by recursive imports. Unfortunately the naive solution didnt really work. I tried to simply not load the file if it already exists in the FileDatabase, but that would disable hot reloading because a file database is not reset before a hot reload. I think it makes sense to make a separate issue to discuss a proposal of a new include system that should support more modularity (so you could import someone else's files without issues) and fix the recursive imports. But that proposal should be possible to implement into the current include system, it might break some Yuck tho... Either way #990