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
Clarification request: should RepoFile permit duplicate Entry elements? #2606
Comments
This class diagram represents my attempt to make sense of the concepts at work here; I hope it helps. |
@technosophos Do you have an idea on this one? I am not quite sure |
Yes, it should allow duplicate entry elements with the same name. What it should not allow are duplicate entry elements with the same name and the same version. e.g. mychart v0.1.0 and mychart v0.2.0 are OK, but mychart v0.1.0 should not be present in the index.yaml a second time. I think this question is out of date now since type ChartRepo uses type *Entry whereas type IndexFile uses a type map[string]ChartVersions. Because it uses a map[string]ChartVersions, every name is guaranteed to be unique due to the inherent nature of a Good question, @ljnelson. |
Thanks for your input. I think, perhaps, you misunderstood my question, or I asked it badly. So: I understand that an What I am not sure about is:
…at least according to the data structure. My question was: is this deliberate? Should the Thanks again for your time and for responding so courteously to this issue. |
From the pkg side yes, but from the CLI side no. This logic should be rolled into the package, though. :) I'll re-open this as a good starter refactor if anyone wants to get their feet wet with |
Thanks. For posterity, my takeaway is: duplicate entries should not be permitted in a |
Correct. :) |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
closing as inactive. |
(Steven Harris ( @seh ) requested that I create this issue after a discussion we had on Slack.)
While working on microbean-helm, I wanted to understand how the
helm
command line tool works with chart repositories. That led me into the Go code around processing (e.g.)~/.helm/repository/repositories.yaml
and (e.g.)~/.helm/repository/cache/stable-index.yaml
.(I am not (yet!) a Go programmer.)
My understanding is that
pkg/repo/repo.go
contains theRepoFile
type for representing the first one, and thatpkg/repo/chartrepo.go
contains theChartRepo
type for representing the second one. Both of them use a type calledEntry
, if I'm reading right, to represent what looks like perhaps a union of information used to represent a "thing" in each file. In the case of aRepoFile
struct,Entry
represents some information you need to talk to a chart repository and there are many of them (as you might expect). In the case of aChartRepo
,Entry
seems to represent kind of like its primary key, and there is only one of them. (I don't know whyEntry
serves this double purpose but I wanted to list what I've learned in case it is helpful here.)At any rate: it looks to me like
RepoFile
"has" anAdd
function that (deliberately?) allows you to add duplicate entries (so I guess this structure allows you to add a representation of a chart repository twice). But then all usage that I can find in the codebase ofRepoFile
structs seems to key off an entry's name (i.e. it treats thisRepoFile
structure like a map in terms of its usage.Is there a reason for permitting duplicates in a
RepoFile
struct?The text was updated successfully, but these errors were encountered: