image-tools
image-tools copied to clipboard
Provide libraries
this project could/should provide libraries around the commands' functionalities so people can write additional tooling.
On Thu, Sep 15, 2016 at 07:56:49AM -0700, Antonio Murdaca wrote:
this project could/should provide libraries around the commands' functionalities so people can write additional tooling.
Work in that direction in opencontainers/image-spec#159 ;). Should I re-open that over here?
Work in that direction in opencontainers/image-spec#159 ;). Should I re-open that over here?
we need to slightly refactor the code at least according to https://github.com/opencontainers/image-spec/pull/234#issuecomment-246798847 before taking into consideration https://github.com/opencontainers/image-spec/pull/159 (there has been no consensus in there also) IMO
On Thu, Sep 15, 2016 at 08:31:38AM -0700, Antonio Murdaca wrote:
Work in that direction in opencontainers/image-spec#159 ;). Should I re-open that over here?
we need to slightly refactor the code at least according to https://github.com/opencontainers/image-spec/pull/234#issuecomment-246798847 …
I already have a callback-based ref walker [1,2](following a @stevvooe suggestion [3]).
I think libraries with fairly stable APIs would be great!
Unpacking can be error-prone, signature validation (once it becomes part of the spec) is not code you want to write yourself and anything that has to do with CAS would be good to share. For all these reasons I would love OCI to expose this functionality through reusable and configurable Go APIs in addition to the CLIs.
@runcom Go doesn't have "libraries" - it has packages. ;)
Indeed, the goal is to provide rich APIs, but I don't think we are even close to a point where we can stabilize an API. The current code is fine for purpose, but I don't think the interface is flexible enough to stand the test of time.
On Thu, Sep 15, 2016 at 12:33:24PM -0700, Stephen Day wrote:
Indeed, the goal is to provide rich APIs, but I don't think we are even close to a point where we can stabilize an API. The current code is fine for purpose, but I don't think the interface is flexible enough to stand the test of time.
Possibly true, but you have to start somewhere ;).
Agree with @wking, starting somewhere and defining a versioned API shouldn't hurt anyone. We can't just wait because we're not at the point to fully stabilize (other projects broke backward compatibility, libraries break compatibility at almost each major release..).
@runcom Go doesn't have "libraries" - it has packages. ;)
Yet are libraries to me, but whatever
is there progress on this? someone want to own this?
umoci
's interfaces are already split up into packages (and I'm currently doing more cleanups in this area in preparation for the merge of the libraries into this project). So as with a bunch of these cleanliness issues, I'm going to end up owning them when umoci
starts to get merged here.
I can dip my toe in, but probably not until late next week; not sure what the timeline is like.
On Thu, Mar 9, 2017 at 3:20 PM, Aleksa Sarai [email protected] wrote:
umoci's interfaces are already split up into packages (and I'm currently doing more cleanups in this area in preparation for the merge of the libraries into this project).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opencontainers/image-tools/issues/2#issuecomment-285516377, or mute the thread https://github.com/notifications/unsubscribe-auth/AABJ6xL27Gezb1sdhYZweMRH7uu5z3VBks5rkIkvgaJpZM4J9-AM .
I'm currently planning on implementing v1.0.0-rc5
support in umoci
's libraries before merging them into this project. Currently that requires some improvements to oci/cas
(which would be the first thing I'd want to move here). oci/casext
is good as-is (though I'd like to add more tests). oci/config/*
is fairly okay though I want to improve some of the interfaces. oci/{diff,layer}
needs some work to make it more useful as a library.
So there are the current things I wouldn't mind getting a hand with (though the v1.0.0-rc5
support is something I'm going to tackle by myself).
Looking forward to seeing the umoci stuff merging in.