@clattner, @GeorgeL and I have an offline thread where we have been discussing a more robust approach to TypeID management, which, among other things, should make it safer for some kinds of additional linking flexibility (an offshoot of Storing a pointer in MLIRContext - #7 by clattner). If implemented, this would help with a number of bugs we currently face when dynamic linking against the core MLIR libraries.
However, there is no currently planned/known way for two unrelated entities that statically link the core MLIR libraries to interop: they will each create their own type universes (and fork access to other statics). If you manage to smuggle c++ pointers between them, I don’t expect it to be a great outcome.
As Alex says, there aren’t a lot of good answers here, and more mature projects also struggle with it a lot by trying to fit within the confines of PyPI deployable wheels (conda has better support for these kinds of complex deployments). We don’t have any immediate plans to publish the MLIR python bindings in this way, because of this uncertainty and their positioning as being a building block - not an end in themselves.
Leaving aside deployment philosophy, making it possible to embed/private label the mlir bindings into an external project is something I want to support (and will need for my own projects in ~months). This will require some reorganization but was planned for, and it would let you have an myproject.mlir.ir, etc. All of the end user facing projects i know of that use these bindings will need that (vs just assuming that the single top level mlir package was built to their specifications).
There is a path for these bindings to be an independently deployable asset, but it would take someone with a real motivation to do that, and so far that person has not emerged 