Hello,
I am hoping that the community can give some insight into the best way
to resolve a particular issue we have here. Let me explain my use case
and apologies for the simplicity of this example.
Use Case:
I have an ivy module called FooBar that produces the artefact FooBar.msi
FooBar depends upon the modules Foo and Bar. Foo exports the artefact
Foo.exe, while Bar exports Bar.h under an interface configuration and
Bar.dll under an implementation configuration.
So to summarise my dependencies are:
FooBar -> Foo
FooBar -> Bar [impl]
Foo -> Bar [iface]
Now I want to produce a proof of concept release called FooBarPoC that
includes BarPoc.dll, however I don't want to make any changes that will
break my original FooBar build. So my options seem to be.
Option1:
Create a new BarPoC module, but keep the original Foo dependency. This
seems wrong as the relationship between the interface and implementation
of Bar and BarPoC are no longer explicit. On the upside it is trivial
to implement.
FooBarPoC -> Foo
FooBarPoC -> BarPoC [impl]
Foo -> Bar [iface]
Option2:
Publish the BarPoC.dll as part of my Bar module and create a new
configuration. This appears to be the "Ivy" way. The interface and
implementations are tightly coupled, however changes to the BarPoC
source code will trigger a build and publish of the entire Bar module
which may cause confusion as it will not be obvious which dll was
changed in each revision.
FooBarPoC -> Foo
FooBarPoC -> Bar [impl-poc]
Foo -> Bar [iface]
Option3:
Do away with configurations completely and instead create BarImpl,
BarIFace and BarPoCImpl modules. This seems to go against the advice in
the Ivy tutorials but it also seems to be the most flexible. Changes to
the BarPoCImpl module do not require a rebuild and publish of BarImpl.
Whereas changes to the BarIFace module will require a rebuild of
everything as expected.
FooBar -> Foo
FooBar -> BarImpl -> BarIFace
FooBarPoC -> Foo
FooBarPoC -> BarPoCImpl -> BarIFace
Foo -> BarIFace
Thank you for getting to the end of this rather long post. So does
anyone have any experience of these three approaches and has found any
of them to be particularly useful or problematic in the long term.
Many thanks.
Jonathan Oulds
