Think about what is the public interface

[leandro-lucarella-frequenz]

Now that we have API documentation, we are exposing every module in the documentation, when the actual classes that are intended to be used by the users are all imported publicly in frequenz.channels.

For a library this small I think it makes sense con only consider that module our public API, this will also allow us to restructure the project in a non-breaking way.

The de facto way to mark modules and packages internal is to prefix a _, so all modules and packages will have to be prefixed this way if we want to go this route.

[leandro-lucarella-frequenz]

Slightly related, I was thinking about putting everything that is not a channel in frequenz.channels.util (i.e. Merge, MergeNamed and Select).

[sahas-subramanian-frequenz]

I'd consider Select, Merge, etc. as core features of the channel implementation, compared to FileWatcher and Timer, that are currently in the utils dir.

So they need to stay closer to the channel implementations than to FileWatcher, etc. If FileWatcher, etc were to move out to a separate repo, then it would make sense, but I'm not so sure otherwise.

[leandro-lucarella-frequenz]

Well, seeing it like this I think we could consider all channels "optional" and only Select being core.

But talking more seriously, what I don't like that much about the current structure is it is not easy to know which class is a receiver and which is a channel (and which is none). If we do:

from frequenz import channels

chan = channels.Broadcast()

It is pretty clear it is a channel, but channels.Merge is confusing (to be honest I only realized that Merge wasn't a channel after a while). This is why at some point I also thought about maybe a receivers package, so:

from frequenz.channels import receivers

recv = receivers.Merge()

But still doesn't look that natural, so util sounded reasonable and was still there.

Another option would be make non-channels more verbose, like MergeReceiver, FileWatchReceiver.

To be honest none of the approaches feels like "YES! This is the one!", so I'm fine with staying with the status quo too if there is nothing clearly more convincing...

[sahas-subramanian-frequenz]

I've been thinking about this too. It would be great to make the implementations internal. This would also make it clear which LSP suggestion to use when importing a type, etc, because there are a number of types we re-export or (internally) reimplement.

[leandro-lucarella-frequenz]

OK, I even have a try locally, so I can create an issue about this and send a PR soon if we agree it is a good approach.

[leandro-lucarella-frequenz]

This was done.