You mentioned only two codepages which are big. If there are indeed only two of them, then I think the simplest option for the users would be to split the lib into three separate libs: common, big codepage 1, and big codepage 2. That way the interface remains straightforward, there’s no need to define a module in the client code, and there will be no duplication, even if multiple client apps use the library.
However, if there are more large codepages, or there’s potential to introduce more of those, then managing one lib per codepage would quickly become too complex for lib maintainers. This is perhaps an opportunity to consider how mix might facilitate such scenario in the future. Perhaps it would be interesting if library authors could provide multiple apps behind a single dependency. That way, the client could specify something like {:some_dep, apps: [:foo, :bar]} to cherry pick the apps it needs from the dependency.
This is incredibly useful information.
