Skip to content
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

Merged
merged 17 commits into from
Dec 21, 2020

Conversation

strega-nil
Copy link
Contributor

@strega-nil strega-nil commented Dec 14, 2020

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:

{
  "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 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.

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.
Copy link
Contributor Author

@strega-nil strega-nil left a 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.

@PhoebeHui PhoebeHui added the category:vcpkg-feature The issue is a new capability of the tool that doesn’t already exist and we haven’t committed label Dec 15, 2020
Copy link
Member

@BillyONeal BillyONeal left a 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 :/ )

Copy link
Contributor

@ras0219-msft ras0219-msft left a 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
@vicroms vicroms added the info:internal This PR or Issue was filed by the vcpkg team. label Dec 18, 2020
@strega-nil strega-nil force-pushed the registries-versions-merge branch 4 times, most recently from a0bc553 to 4fe7b03 Compare December 18, 2020 22:19
@strega-nil strega-nil force-pushed the registries-versions-merge branch from 4fe7b03 to 360217b Compare December 18, 2020 22:29
Copy link
Member

@BillyONeal BillyONeal left a 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.

@strega-nil strega-nil force-pushed the registries-versions-merge branch from 5494373 to 260d25e Compare December 21, 2020 20:07
@strega-nil
Copy link
Contributor Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@strega-nil strega-nil merged commit c898283 into microsoft:master Dec 21, 2020
Jimmy-Hu added a commit to Jimmy-Hu/vcpkg that referenced this pull request Dec 22, 2020
[vcpkg registries] support versions (microsoft#15114)
Copy link
Contributor

@ras0219 ras0219 left a 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


if (!regs.empty() && !registries_enabled)
{
registries_feature_flags_warning = true;
regs.clear();
}

if (!r.errors().empty())
{
return nullopt;
Copy link
Contributor

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).


if (!regs.empty() && !registries_enabled)
{
registries_feature_flags_warning = true;
regs.clear();
}

if (!r.errors().empty())
Copy link
Contributor

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);
Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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;
Copy link
Contributor

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<>.

ryukw7 pushed a commit to ryukw7/vcpkg that referenced this pull request Dec 24, 2020
* [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.
@strega-nil strega-nil deleted the registries-versions-merge branch January 19, 2021 19:51
strega-nil added a commit to strega-nil/vcpkg that referenced this pull request May 5, 2021
* [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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:vcpkg-feature The issue is a new capability of the tool that doesn’t already exist and we haven’t committed info:internal This PR or Issue was filed by the vcpkg team.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants