Closed elezar closed 5 months ago
/cc @pohly
@klihub @bart0sh as a general question, I was wondering whether we should actually REMOVE the ToOCI
functions here instead (in practice we would make them private). My motivation is that these functions do not make sense in isolation and are only consumed from the Apply
functions which actually update the spec.
If we do have clients that use these directly, we can consider how to better add these APIs.
@klihub @bart0sh as a general question, I was wondering whether we should actually REMOVE the
ToOCI
functions here instead (in practice we would make them private). My motivation is that these functions do not make sense in isolation and are only consumed from theApply
functions which actually update the spec.If we do have clients that use these directly, we can consider how to better add these APIs.
@elezar Good point. If with this change we don't have cross-package use any more then I think making them private makes sense, since/if we don't consider them useful for external users
@klihub I have updated the latest revision with private functions. PTAL.
LGTM
This change removes the ToOCI functions from the specs-go package. They are implemented as private toOCI functions in the cdi package instead. This means that there is no dependency on the OCI runtime spec for clients that only need a CDI spec definition.
NOTE: This is a breaking change in that the
ToOCI
functions no longer exist in thespecs-go
module, but the impact of this should be minimal and is worth the removal of therequire github.com/opencontainers/runtime-spec
dependency from the spec definitions.