Comments (5)
If you think with can replace docker/docker
with docker/distribution
dependency, we would be happy to make PRs that implement the required changes. WDYT?
from image.
just a quick reply w/o actually looking at the whole code I think this is reasonable if it can be done, ping @mtrmac
from image.
Hello,
containers/image imports
docker/docker
for thereference
package which is used for types of for reference parsing.docker/docker
is a quite big repository and would prefer to avoid having it as a dependency in GrootFS, which consumescontainers/image
.Would it be possible to use
docker/distribution
instead for the reference types/parsing?
Not trivially; we use the canonicalization facilities from docker/distribution
(FullName
and the effect of normalize
).
Of course this could be copy&pasted into this repo, at the risk of divergence.
But we explicitly went the other way in #32 , though there is little discussion about rationale in there.
Additionally, the Docker transport package seems to be doing all the requests to a Docker registry [3]. Could this behavior be delegated to
docker/distribution
?
That would probably be possible, I have no idea about the cost/benefit. To the extent the current code “works” (admittedly it’s not nearly as polished as docker/distribution
) I wasn’t personally motivated to change it, though that wouldn’t prevent accepting a PR of course.
In abstract the question is whether to import from external dependencies to avoid behavior divergence and effort duplication, or whether to copy&paste / reimplement to avoid breakage on API or behavior changes, and possibly to make it easier to change things. I don’t think we have a consistent answer to this trade-off, and the suggestion to avoid pulling in docker/reference
but to depend on docker/distribution
also shows that making a simple rule is difficult.
My personal preference would generally be towards using external dependencies and not duplicating the work, OTOH I haven’t been around docker/docker
long enough to know how painful it can be.
As a first impression, “docker/docker is a big git repo” seems a fairly weak reason to duplicate the docker/distribution
code; though it is unfortunate how the github.com/docker/docker/image/v1
reference in there pulls in much more than we really need.
@runcom , #32 was your PR originally. Any thoughts on that?
from image.
as you perfectly explained - even if docker is a big git repo, it is moving fast and we could lose bits (which could be bug fixes). So the rationale behind that PR was to avoid moving away from docker as it's not an issue to depend on them (unless of course you take into account the size of that repo)
from image.
Thanks @mtrmac and @runcom. Copying and pasting small chunks of code is usually better than a dependency, but I understand that in this case docker/docker/reference
provides us with canonicalization behaviour that we don't want to regress against.
On using docker/distribution
for the interaction with the registry, I am happy to know that you would consider a PR. The cost is certainly high and possibly higher than what we would be willing to pay for what we want to achieve currently. I will open a new issue soon to become more specific on that.
Thanks!
from image.
Related Issues (20)
- [Clarification] copy.CopySpecifcImages and Instances list HOT 2
- Is the new LayersData field the compressed size? HOT 7
- internal/signature.FromBlob is not forward-compatible
- Dependency Dashboard
- Support copying images for specific platforms/architectures HOT 2
- Multiple copies of the default signature policy path
- storage tests are mostly broken when run as root
- ENOEXEC with a credential helper HOT 6
- Support Docker image references with tag and digest HOT 6
- [feature request][performance] sort layers by size before remote-to-remote copy HOT 8
- Support for non-TLS HTTP HOT 5
- pull by digest broken on aes encrypted image pushed to dockerhub HOT 2
- Some sequence of multiple GPGME mechanisms / signing + verification operations causes hangs
- Support custom header in registry HOT 1
- Feature request - skopeo delete - oci transport support HOT 1
- Allow referring images in oci: (and oci-archive: ?) by manifest digest HOT 8
- Disable Dependabot filing version updates HOT 2
- Add support for OCI artifacts “attached” to an image via `subject` HOT 3
- `GetDigest` could skip API call when passed a digest HOT 1
- Ambiguous discussion of detached signature in containers-signature.5.md HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from image.