-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
[vcpkg registries] support versions #15114
[vcpkg registries] support versions #15114
Conversation
This PR merges the Registries changes and the versioning changes, so that one can use both at the same time. There is one major difference between this PR and the RFC (microsoft#13590), which is that instead of version files looking like: ```json [ ... ] ``` version files look like: ``` { "versions": [ ... ] } ``` this is to support interop between this PR and existing demos and the like; fixing this, along with perhaps renaming `port_versions` to `port-versions` should be done after this is merged, should be a trivial change.
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.
These are the things I noticed and am fixing now, along with some notes.
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 feel bad that I don't have substantial code review comments, because most of this is parsing code etc. and I don't think humans in general are very good at reviewing that without debugging through examples or having complete test coverage.
I do think this needs some tests before it is merged. (I don't if versions had test coverage but had I been around to review that I'd probably have made the same comment :/ )
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.
Review still in progress (portfileprovider.cpp:299)
switch to using the same git archive trick which is used in the git registry pr
a0bc553
to
4fe7b03
Compare
4fe7b03
to
360217b
Compare
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 still would really like to see unit level tests for any parsing code that aren't present here.
5494373
to
260d25e
Compare
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
[vcpkg registries] support versions (microsoft#15114)
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.
@strega-nil Please consider opening a new PR that addresses these issues
toolsrc/src/vcpkg/configuration.cpp
Outdated
|
||
if (!regs.empty() && !registries_enabled) | ||
{ | ||
registries_feature_flags_warning = true; | ||
regs.clear(); | ||
} | ||
|
||
if (!r.errors().empty()) | ||
{ | ||
return nullopt; |
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.
nullopt
implies to the caller that the current object is completely outside the bounds of the current deserializer to handle -- for example, asking StringDeserializer
to operate on null
or 10
. The caller will then emit a message to the effect of Error: expected $.field to be of type string
.
However, in this case, you're (presumably?) trying to test for whether an error was emitted above as part of parsing the optional object fields. If one of those did result in an error, then the user will already see that more specific error and does not need the generic one.
This is fixed by returning a default constructed object of some kind; the code consuming this deserializer should handle this case accordingly (either by testing r
for errors if it's outside the deserializer framework or handling the default constructed form if within the deserializer framework).
toolsrc/src/vcpkg/configuration.cpp
Outdated
|
||
if (!regs.empty() && !registries_enabled) | ||
{ | ||
registries_feature_flags_warning = true; | ||
regs.clear(); | ||
} | ||
|
||
if (!r.errors().empty()) |
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.
This is almost certainly not the right condition -- this will test whether any errors have occurred anywhere in the reader to this point, not just in child objects.
If you need to detect errors in child objects and return early, you'll need to check those objects for an appropriate error state (empty collection, etc).
auto maybe_error = | ||
p->source_control_file->check_against_feature_flags(p->source_location, paths.get_feature_flags()); | ||
if (maybe_error) return std::move(*maybe_error.get()); | ||
auto port_path = port->get_path_to_version(paths, port_version).value_or_exit(VCPKG_LINE_INFO); |
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.
This should probably propagate the error to the caller instead of crashing (based on the function signature)
const Optional<std::string> m_baseline; | ||
Lazy<Optional<std::map<std::string, VersionT, std::less<>>>> baseline_cache; | ||
mutable std::unique_ptr<PathsPortFileProvider> m_portfile_provider; | ||
const VcpkgPaths& paths; // TODO: remove this data member |
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.
const VcpkgPaths& paths; // TODO: remove this data member | |
const VcpkgPaths& paths; |
Or remove it :)
Lazy<Optional<std::map<std::string, VersionT, std::less<>>>> baseline_cache; | ||
mutable std::unique_ptr<PathsPortFileProvider> m_portfile_provider; | ||
const VcpkgPaths& paths; // TODO: remove this data member | ||
mutable std::map<std::string, Optional<VersionT>, std::less<>> m_baseline_cache; |
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.
This could use vcpkg::Cache<>
.
* [vcpkg registries] support versions This PR merges the Registries changes and the versioning changes, so that one can use both at the same time. There is one major difference between this PR and the RFC (microsoft#13590), which is that instead of version files looking like: ```json [ ... ] ``` version files look like: ``` { "versions": [ ... ] } ``` this is to support interop between this PR and existing demos and the like; fixing this, along with perhaps renaming `port_versions` to `port-versions` should be done after this is merged, should be a trivial change.
* [vcpkg registries] support versions This PR merges the Registries changes and the versioning changes, so that one can use both at the same time. There is one major difference between this PR and the RFC (microsoft#13590), which is that instead of version files looking like: ```json [ ... ] ``` version files look like: ``` { "versions": [ ... ] } ``` this is to support interop between this PR and existing demos and the like; fixing this, along with perhaps renaming `port_versions` to `port-versions` should be done after this is merged, should be a trivial change.
This PR merges the Registries changes and the versioning changes, so that one can use both at the same time.
There is one major difference between this PR and the RFC (#13590), which is that instead of version files looking like:
[ ... ]
version files look like:
this is to support interop between this PR and existing demos and the like;
fixing this, along with perhaps renaming
port_versions
toport-versions
should be done after this is merged,should be a trivial change.
This is the first PR resulting from splitting #15054 into multiple PRs.
The e2e tests for filesystem registries will come in the git registries PR, since there's already test code written for that.