Oh, I see. I was adressing what I said earlier: I wonder if I can modify the library with pre-packaged .beam files that represent all coding pages, compiled on my machine.
But then I stumble upon the problem of striking a balance between a minimum Erlang version that (1) ensures maximum backwards compatibility but (2) ensures fast code.
(Michal mentioned missing out on improved APIs or improved compiler.)
Why would you do that? As you can see there are clearly some issues with this approach, so I wonder what is the gain?
Mostly to dodge the original problem that sparkled this discussion – so people don’t have to dig about mix deps.compile codepagex --force after they have already installed the library and now want to add coding pages.
Also trying to figure out a good solution that doesn’t choke CI/CD machines.
There are simpler and more reliable ways of achieving this, for example by having the library accept the parameters via macro or function args, or by generating and exposing all the modules for all supported encodings (but doing it during compilation, not offering them as external .beam files).
Given that binaries are usually cached on such machines, I wouldn’t expect this to be a problem.
Okay, I am beaten. 
Do you stand by behind your initial suggestion on how to improve Codepagex or do you now think you’d do it another way?
I didn’t really look deeper into the library so I can’t make stronger recommendations. That said, based on this discussion, I see the following options:
In this approach, we’d be able to invoke something like Codepagex.CP1251.from_string(...)
I believe this is the most straightforward solution, and it’s the one I’d try first. Possible blocker is that this might increase the first compilation time, and cause a significant disk/memory usage overhead. I think it should be tried out, and the overhead should be measured.
use solution I originally proposedIn this approach, the client can cherry pick the encodings it needs, so we generate the minimal amount of code. The interface is a bit clumsier, but it resolves possible blockers from #1.
There are some other options that could be considered, such as deferring the decision to runtime, or splitting the library into multiple libraries, but for a few reasons I’m not inclined to try out those (again, I didn’t study the lib code in details, so my assumptions might be wrong).
Hi. Id be happy to improve the interface for Codepagex. Some of the encodings are quite large an this is why Codepagex is configurable in the first place. Option 2 seems fine, except it seems a bit clumsy. An option where codepages are dynamically compiled on use seems to be the best option, I’d have to think about how this could be implemented.
Whatever I/we decide here, compatibility will also be an issue here, as Codepagex does compile a few codepages by default, and changing the selection algorithm could break code
Speaking on the subject of Codepagex, there is still one important feature missing which is support for io lists. These would boost performance as for many conversins, string parts could be reused..
For encoding big bunches of behavior into elixir modules one can look into ex_cldr. It‘s taking the officially provided json files and generates modules based on them.
If the external files → code translation should happen not on the library users machine it could also be done like e.g. nimble_parsec does it with generating a already processed elixir module, which would then be published.