feat: support channel in CLI cut command - #22
Conversation
This map will be needed when implementing the channel filter.
letFunny
left a comment
letFunny
left a comment
There was a problem hiding this comment.
It also looks very good. I have to admit channel + risk + track are not the simplest concepts to keep in mind but I think it has been a good job mapping those into Chisel.
| Slices are named <package>_<slice>. For packages coming from a store, a | ||
| channel may be appended to select which one to fetch, as in | ||
| mybin_myslice@2.0/edge. A channel with no risk, such as @2.0, uses the | ||
| stable risk. |
There was a problem hiding this comment.
Should you mention if not the default track in the package yaml is used?
There was a problem hiding this comment.
This is already in the last sentence of the next paragraph. Is it too disjointed?
There was a problem hiding this comment.
The first time I read it I thought it referred to multiple slices of the same package. This is up to personal opinion but I would move it to before you talk about multiple slices.
There was a problem hiding this comment.
I reworked it a bit, also trying to clarify how the channel is composed.
| // Only report the channels of the selected packages. | ||
| selection.Channels = make(map[string]string) |
There was a problem hiding this comment.
Is this necessary, it seems that channels is already built from the references of the selection and nothing more.
There was a problem hiding this comment.
No, it also contains entries for all store packages (see the loop discussed above) because this is done before the call to order that will need the channels map in the follow-up PR (to pick essentials or not). I don't want to merge something in this PR that will be immediately reworked in the next one, hence the loop above.
| } | ||
|
|
||
| func (c Channel) String() string { | ||
| if c.Track == "" { |
There was a problem hiding this comment.
How can this be empty? I suspect it is the upper layer that has the channel unset, right? If that is the case another approach is to use nil vs channel, I don't know which one is more readable.
There was a problem hiding this comment.
The function was misrepresenting a Channel. This is now fixed, also making it obvious when the Channel object is "wrong".
2 participants
Allow selecting a channel when cutting slices from store packages (bins), via a
pkg_slice@channelsuffix on the command line.Unlike debs, bins are published per channel, so users need to pick which one to fetch; a bare
@3.0is treated as a track and gets the default risk (stable), while@3.0/edgeis used as given. When no suffix is provided, the channel is derived from the package'sdefault-trackin the slice definition, which stays a track — the risk remains implicit on the YAML side. The channel is kept strictly separate from slice identity: it flows only from the reference throughsetup.SelectintoSelection.Channelsfor the slicer to consume at fetch time, leaving dependency resolution, conflict checks and the manifest untouched. Conflicting channels for slices of the same package and channels on non-store packages are rejected,info/findcommands reject the@suffix since it is only meaningful when cutting, and channel validation is intentionally loose so longer forms such astrack/risk/branchare not rejected today.NOTE: This PR only prepares a Channels map in the Selection. Subsequent work to fetch bins from the store will consume it to get the right revision.