-
Notifications
You must be signed in to change notification settings - Fork 0
add cep for sigstore #5
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
Conversation
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
| - `targetChannel` **MUST** be a string, indicating where the package | ||
| is being uploaded to. This field **MUST** be a valid URL with no | ||
| trailing slashes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flagging: the original language said "canonical URL" for the targetChannel, but I couldn't find a clear resource on what canonicalization of channel URLs looks like in the conda ecosystem. Does conda have a definition for a "canonical" URL, or by "canonical" did you mean something like "official"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this is becoming a bit of a problem for the conda ecosystem these days. Currently, when you say -c conda-forge, the URL is resolved to https://conda.anaconda.org/conda-forge which is the "default" place for teh open source channels. But I think we want to be more precise and you should indicate the URL that matches exactly with the channel that you would also download the package from later, whcih can reside on different hosts (for example, for prefix.dev it would look like https://prefix.dev/my-channel).
A channel / organization would have to decide for themselves where the primary channel lives (and which URLs are merely mirrors). For example, for conda-forge right now this would be https://conda.anaconda.org/conda-forge. At some point the organization might decide to switch to https://prefix.dev/conda-forge - at which point we'd have to configure clients to trust either those two, or make a decision based on a timestamp which one is the primary source during what periods.
I also have a proposal open for a community governed channel registry that would live e.g. as a JSON file on Github: conda#91
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
WIP; just pushing something up for visibility 🙂
Signed-off-by: William Woodruff [email protected]