Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide libraries #2

Open
runcom opened this issue Sep 15, 2016 · 12 comments
Open

Provide libraries #2

runcom opened this issue Sep 15, 2016 · 12 comments

Comments

@runcom
Copy link
Member

runcom commented Sep 15, 2016

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

@wking
Copy link
Contributor

wking commented Sep 15, 2016

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?

@runcom
Copy link
Member Author

runcom commented Sep 15, 2016

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 opencontainers/image-spec#234 (comment) before taking into consideration opencontainers/image-spec#159 (there has been no consensus in there also) IMO

@wking
Copy link
Contributor

wking commented Sep 15, 2016

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
opencontainers/image-spec#234 (comment)

I already have a callback-based ref walker [1,2](following a @stevvooe
suggestion [3]).

@glestaris
Copy link
Contributor

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.

@stevvooe
Copy link
Contributor

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

@wking
Copy link
Contributor

wking commented Sep 15, 2016

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

@runcom
Copy link
Member Author

runcom commented Sep 15, 2016

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

@vbatts
Copy link
Member

vbatts commented Mar 9, 2017

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

@cyphar
Copy link
Member

cyphar commented Mar 9, 2017

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.

@erikh
Copy link
Contributor

erikh commented Mar 10, 2017 via email

@cyphar
Copy link
Member

cyphar commented Mar 10, 2017

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

@jonboulle
Copy link
Contributor

Looking forward to seeing the umoci stuff merging in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants