[RFC] A better include/import system +modules/namespaces?

[max-ishere]

I noticed a slight issue with Yuck and how the include system works. First of all the includes are just OS paths relative to either the config directory or the root of the filesystem. Secondly, recursive imports stack overflow Eww causing a crash.

This was first mentioned in #982 and then implemented in #986. While relative imports were quite easy to implement the recursive imports require some more work to fix. Solving the crash is possible in the current system, I just think a better include system would be nice to have. This is the purpose of this thread. To discuss a potential alternative to the current way of including files in Yuck. This rework would be a breaking change, potentially too breaking which is why I am requesting for comment.

The most basic change

The smallest thing that can be done is keeping the current system, adding relative imports, adding some more elaborate logic to prevent recursive imports from crashing Eww (thus allowing a recursive include and considering it ok) and not introducing any breaking changes. There is nothing wrong with this option.

Following is a set of optional changes, and we don't have to implement all (or any) of them.

A Rust mod-like system

A set of constraints can be introduced, similar to the Rust mod system, which would make a recursive include impossible. This is achieved by creating an equivalent of mod.rs (e.g. eww.yuck), which is the only file that can declare modules (include other files). We can also make an exception that a file named A.yuck can include files in the A directory, but then the A directory can no longer contain a mod.rs-kind-of-file (eww.yuck / mod.yuck, etc). These constraints will only allow one directional include statements going down or sideways (but never back) on the filesystem.

A namespace system

Namespaces have a good use - they can help the user combine their own configuration with someone else's config while removing name collisions. This however is quite a complex system and the effort is not easily justified. There just aren't any requests for it. The only reason I'm including it here is because it makes automated tools such as a package manager or a store (discussed in #948) easier to implement.

The idea is to somehow decide on a namespace boundary (go defines it as: all files on the same level are the same module and thus namespace, Rust defines each file as a namespace). Then introducing a way to use all/some widgets from a namespace as well as an aliasing system. The aliasing system would be especially useful in the top-level eww.yuck to name windows in more concise formats (e.g: renaming sway-bar::Window with bar).