-
Notifications
You must be signed in to change notification settings - Fork 114
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
Make "estargz" pkg import-friendly #194
Comments
Yeah, so I'd love it if this could be split into its own standalone module (a la Context: I want to see us leverage this in some of the core utilities in google/go-containerregistry (aka GGCR): google/go-containerregistry#866 If GGCR needs to vendor something from stargz-snapshotter, then (at the This might shake out ok now because pruning, but generally projects with cycles at the IDK yet whether this is blocking for GGCR prototyping, but I think it is something we should consider before merging that support regardless. Just to reiterate here, I am a BIG fan of this work 🙏, and am poking everyone I can to pay attention, so if you think there are ways I can help support this, please reach out. |
Closing this as |
Starting to pull it in here: google/go-containerregistry#870 thanks! |
Currently, the consumer of "estargz" pkg needs to
go mod
this project (that includes snapshotter & fs codes as well).Because of that, there seem cases where a dependency cycle is created (https://twitter.com/mattomata/status/1337270338221064192).
@mattmoor Could you elaborate the current dependency cycle you are facing? Splitting out estargz to another project is a big change (approval is needed for creating a new repo under containerd) so we first would like to find a way to solve that dependency cycle in the current repository structure.
cc: @AkihiroSuda
The text was updated successfully, but these errors were encountered: