-
Notifications
You must be signed in to change notification settings - Fork 376
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
Fix channel
and base_url
in list
cmd
#3488
Conversation
8651f0f
to
1221fed
Compare
00059be
to
105e18e
Compare
"https://pkg-containers.githubusercontent.com/ghcr1/blobs/pandoc" | ||
) | ||
assert pkg["base_url"] == "https://pkg-containers.githubusercontent.com/ghcr1/blobs" | ||
assert pkg["channel"] == "https://pkg-containers.githubusercontent.com/ghcr1/blobs" |
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.
We could set this to something else like oci
or ghcr
?
But that could be done in another PR once it's all sorted out.
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 let's fix the bugs for now;, and figure out what to do for OCI in a dedicated PR.
// This is more or less an implementation of `util::rstrip` specific to this use case | ||
// (for printing purposes), but using `std::string` instead of `std::string_view` | ||
// `util::rstrip` is not used here because it leads to an UB, | ||
// `using non owned/tracked strings from Channel (& co) and PackageInfo |
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.
Not sure to understand why util::rstrip
leads to UB. Is it still the case if you assign its result to a std::string
?
Anyway, if we keep this implementation, we should open an issue to try to fix the UB and use a single implementation of rstrip.
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.
Well, since we use it recursively, it will imply doing a lot std::string
conversions?
Not sure if doing this is cleaner than just having a string version for rstrip
?
Anyway, I agree that we should definitely reevaluate.
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.
I meant using the funciton degined in util::string
and assign the final result of the recursive call to a string. The function returns temporary string_view passed by copies, so there hsould not be any dangling temporary issues.
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.
Well doing:
std::string res = std::string(util::rstrip(util::rstrip(util::rstrip(util::rstrip(full_str, filename), "/"), platform), "/"));
instead of using the reimplemented rstrip
in strip_from_filename_and_platform
definitely leads to UB, if that's what you meant.
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.
yep that's what I meant :( OK let's merge as is and open an issue to fix that UB later
"https://pkg-containers.githubusercontent.com/ghcr1/blobs/pandoc" | ||
) | ||
assert pkg["base_url"] == "https://pkg-containers.githubusercontent.com/ghcr1/blobs" | ||
assert pkg["channel"] == "https://pkg-containers.githubusercontent.com/ghcr1/blobs" |
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 let's fix the bugs for now;, and figure out what to do for OCI in a dedicated PR.
I agree that we may reintroduce the canonical_name in a future PR. |
Fix #3480
The channel name used in
1.x
was dropped during the "Great refactoring" (under the assumption, IIUC, that it's the same ascanonical_name
, which was not always true...) and now that info is stored/computed nowhere.Since this is only used in the
list
command, it's handled this way for now...