image-tools icon indicating copy to clipboard operation
image-tools copied to clipboard

Provide libraries

Open runcom opened this issue 8 years ago • 12 comments

this project could/should provide libraries around the commands' functionalities so people can write additional tooling.

runcom avatar Sep 15 '16 14:09 runcom

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?

wking avatar Sep 15 '16 15:09 wking

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

runcom avatar Sep 15 '16 15:09 runcom

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]).

wking avatar Sep 15 '16 15:09 wking

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.

glestaris avatar Sep 15 '16 16:09 glestaris

@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.

stevvooe avatar Sep 15 '16 19:09 stevvooe

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 ;).

wking avatar Sep 15 '16 19:09 wking

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

runcom avatar Sep 15 '16 20:09 runcom

is there progress on this? someone want to own this?

vbatts avatar Mar 09 '17 16:03 vbatts

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.

cyphar avatar Mar 09 '17 23:03 cyphar

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 .

erikh avatar Mar 10 '17 00:03 erikh

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).

cyphar avatar Mar 10 '17 09:03 cyphar

Looking forward to seeing the umoci stuff merging in.

jonboulle avatar Mar 10 '17 11:03 jonboulle