Referring to Ent code in a shared library and allowing library users to replace it with their own Ent generations. #3898
Unanswered
preslavrachev
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I’m at an interesting conundrum. I’m building a library that depends on Ent's generated code in a package (basically, it needs a references to an Ent DB client). The problem is, I want users of this lib to be able to generate their own clients, “shadowing” the original package dependency.
I am well aware of the avsailable alternatives (e.g. empty interfaces, generics) and neither is going to make it. Partly, because the functions that create, as well as the types that represent configuration options are also part of the generated code.
The solution I came up with is as hacky as one could think of but it seems to work for now. I am interested to hear from you what other possibilities I might have.
ent
package, which has the minimum generated code to have anent.Client
it can refer to.ent
package is actually its own separate module (it has its owngo.mod
file)ent
package, whch is also a module (bearing the same name as the one of library'sent
module)go.mod
file of the library user, I add areplace
directive, which maps the package name to the localent
folder. This effectively "replaces" the one seen by the library with the local one.So far, things seem to work, but again, I am not in favor of this approach.
Beta Was this translation helpful? Give feedback.
All reactions