https://pantsbuild.org/ logo
Join Slack
Powered by
I'm going over <@U01PZK60W2F>’s new docs for the d...
# development
h
I'm going over @curved-television-6568’s new docs for the docker publishing functionality, and it occurs to me that there is a bit of a terminology mismatch. But I might be wrong because I don' t use Docker daily, so bringing it up here for discussion:
👍 1
AFAICT Docker has two concepts: Repository and Tag
For example 
postgresql
is a repository, and 
13.4
is a tag within that repository
We have introduced "repository", "image_name" and "tag"
our tag is the same as Docker tag, so let's put that to one side
We, I think, combine our repository and image_name into 
<repository>/<image_name>
and this is used as the Docker repository concept
Am I understanding correctly?
And assuming so, what is the purpose of this? Does this match how people use the 
repository
in practice?
I'm thinking we should clarify our own terminology to match Docker's?
Or even simplify and get rid of the two-part naming?
c
+1 for simplifying. In the Docker space, you really only have the image tag, which is made up of a name part and a tag part (used as version, defaults to latest) separated with a colon. And yes, I think this concept isn’t super clear either, but is what it is for historical reasons I suppose. The name part then has parts, each separated with a slash. What these parts mean is not dictated by Docker, but a common concept is to have repository/name, while Docker hub have username/repo.
Given the name template, we could probably get rid of the repository field.. or perhaps just find better names for the various parts..?
Would be happy to get more input from other Docker users here, to hear their take on this :)
a
i think things get more confusing as there's also a registry (the storage location) so for 
<http://eu.gcr.io/mycompany/image:123|eu.gcr.io/mycompany/image:123>
<http://eu.gcr.io/mycompany|eu.gcr.io/mycompany>
is the registry 
<http://eu.gcr.io/mycompany/image|eu.gcr.io/mycompany/image>
is the repository 
123
is the tag and you can have an infinite combinations of each all pointing to a single image.
and really, when building do you want to use the 'full' 
FROM <http://eu.gcr.io/mycompany/base:123|eu.gcr.io/mycompany/base:123>
in all your dockerfiles? I think it's pretty common to do 
ARG registry='mycompany'; FROM ${registry}/base:123
👍 1
w
I think a field called "image tags" may be sufficient. That's how the docker/podman api works for build already, right? No need to try and interpret what those tags may mean. On the other hand, it could make bumping versions more of a hassle.
h
So @curved-television-6568 how do you feel about getting rid of the target-level distinction between name and repository, and just having repository, which defaults to path/to/target/name but can be overridden?
c
@ambitious-actor-36781 yea, that’ll work with the build args https://github.com/pantsbuild/pants/pull/13147 Exactly how we do it too..
@happy-kitchen-89482 yep, I can get rid of the 
image_name
field. I think there’s enough flexibility already with the name template option.
@worried-salesclerk-37834 agree we should not try to interpret anything, or not too much at least. At the same time offer constructs to support keeping the BUILD files DRY, so I think we need to do some assembling of the image tag.
h
Great, so I'll hold off on more document review until that's done
👍 1
c
Hopefully improved the situation with this PR https://github.com/pantsbuild/pants/pull/13225
Open in Slack
PreviousNext
Powered by