error: Pull the RFC 2119 error representation into its own package #437
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As discussed in [1]. This makes it easier for other projects (e.g. image-tools) to use the same tooling if they want. Some components of the old validate/error.go were runtime-spec-specific (e.g. the reference template and ociErrors), so they've stayed in the validate package. I've also expanded NewError to take an explicit version (as requested in [2]). That allows us to link to the proper spec even if we're capable of validating several spec versions (e.g. 1.0 and 1.1 configurations or runtimes). [1]: opencontainers#354 (comment) [2]: opencontainers#354 (comment) Signed-off-by: W. Trevor King <[email protected]>
wking
force-pushed
the
separate-error-package
branch
from
ac6ecb0 to
8f4d367
Compare
|
LGTM |
1 similar comment
|
LGTM |
wking
added a commit
to wking/ocitools-v2
that referenced
this pull request
Aug 30, 2017
…kage With 8f4d367 (error: Pull the RFC 2119 error representation into its own package, 2017-07-28, opencontainers#437), I'd created a package that was completely independent of runtime-spec. As I pointed out in that commit message, this made it possible for image-tools and other projects to reuse the generic RFC 2119 handling (which they care about) without involving the runtime-spec-specific error enumeration and such (which they don't care about). In 2520212 (add stretchr/testify/assert pkgs; use rfc code in bundle validation, 2017-08-29, opencontainers#451), some runtime-spec-specific functionality leaked into the error package. I'd recommended keeping configuration and runtime requirements separate [1], because you're unlikely to be testing both of those at once. But Liang wanted them collected [2,3]. And the NewError and FindError utilities would be the same regardless of target, so that's a good argument for keeping them together. This commit moves the runtime-spec-specific functionality into a new package where both config and runtime validators can share it, but where it won't pollute the generic RFC 2119 error package. I've also changed NewError to take an error argument instead of a string message, because creating an error from a string is easy (e.g. with fmt.Errorf(...)), and using an error allows you to preserve any additional structured information from a system error (e.g. as returned by GetMounts). [1]: opencontainers#451 (comment) [2]: opencontainers#451 (comment) [3]: opencontainers#451 (comment) Signed-off-by: W. Trevor King <[email protected]>
wking
added a commit
to wking/ocitools-v2
that referenced
this pull request
Aug 30, 2017
…kage With 8f4d367 (error: Pull the RFC 2119 error representation into its own package, 2017-07-28, opencontainers#437), I'd created a package that was completely independent of runtime-spec. As I pointed out in that commit message, this made it possible for image-tools and other projects to reuse the generic RFC 2119 handling (which they care about) without involving the runtime-spec-specific error enumeration and such (which they don't care about). In 2520212 (add stretchr/testify/assert pkgs; use rfc code in bundle validation, 2017-08-29, opencontainers#451), some runtime-spec-specific functionality leaked into the error package. I'd recommended keeping configuration and runtime requirements separate [1], because you're unlikely to be testing both of those at once. But Liang wanted them collected [2,3]. And the NewError and FindError utilities would be the same regardless of target, so that's a good argument for keeping them together. This commit moves the runtime-spec-specific functionality into a new package where both config and runtime validators can share it, but where it won't pollute the generic RFC 2119 error package. I've also changed NewError to take an error argument instead of a string message, because creating an error from a string is easy (e.g. with fmt.Errorf(...)), and using an error allows you to preserve any additional structured information from a system error (e.g. as returned by GetMounts). [1]: opencontainers#451 (comment) [2]: opencontainers#451 (comment) [3]: opencontainers#451 (comment) Signed-off-by: W. Trevor King <[email protected]>
wking
added a commit
to wking/ocitools-v2
that referenced
this pull request
Aug 31, 2017
…kage With 8f4d367 (error: Pull the RFC 2119 error representation into its own package, 2017-07-28, opencontainers#437), I'd created a package that was completely independent of runtime-spec. As I pointed out in that commit message, this made it possible for image-tools and other projects to reuse the generic RFC 2119 handling (which they care about) without involving the runtime-spec-specific error enumeration and such (which they don't care about). In 2520212 (add stretchr/testify/assert pkgs; use rfc code in bundle validation, 2017-08-29, opencontainers#451), some runtime-spec-specific functionality leaked into the error package. I'd recommended keeping configuration and runtime requirements separate [1], because you're unlikely to be testing both of those at once. But Liang wanted them collected [2,3]. And the NewError and FindError utilities would be the same regardless of target, so that's a good argument for keeping them together. This commit moves the runtime-spec-specific functionality into a new package where both config and runtime validators can share it, but where it won't pollute the generic RFC 2119 error package. I've also changed NewError to take an error argument instead of a string message, because creating an error from a string is easy (e.g. with fmt.Errorf(...)), and using an error allows you to preserve any additional structured information from a system error (e.g. as returned by GetMounts). [1]: opencontainers#451 (comment) [2]: opencontainers#451 (comment) [3]: opencontainers#451 (comment) Signed-off-by: W. Trevor King <[email protected]>
wking
added a commit
to wking/ocitools-v2
that referenced
this pull request
Sep 1, 2017
…kage With 8f4d367 (error: Pull the RFC 2119 error representation into its own package, 2017-07-28, opencontainers#437), I'd created a package that was completely independent of runtime-spec. As I pointed out in that commit message, this made it possible for image-tools and other projects to reuse the generic RFC 2119 handling (which they care about) without involving the runtime-spec-specific error enumeration and such (which they don't care about). In 2520212 (add stretchr/testify/assert pkgs; use rfc code in bundle validation, 2017-08-29, opencontainers#451), some runtime-spec-specific functionality leaked into the error package. I'd recommended keeping configuration and runtime requirements separate [1], because you're unlikely to be testing both of those at once. But Liang wanted them collected [2,3]. And the NewError and FindError utilities would be the same regardless of target, so that's a good argument for keeping them together. This commit moves the runtime-spec-specific functionality into a new package where both config and runtime validators can share it, but where it won't pollute the generic RFC 2119 error package. I've also changed NewError to take an error argument instead of a string message, because creating an error from a string is easy (e.g. with fmt.Errorf(...)), and using an error allows you to preserve any additional structured information from a system error (e.g. as returned by GetMounts). [1]: opencontainers#451 (comment) [2]: opencontainers#451 (comment) [3]: opencontainers#451 (comment) Signed-off-by: W. Trevor King <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed here. This makes it easier for other projects (e.g. image-tools) to use the same tooling if they want. Some components of the old
validate/error.gowere runtime-spec-specific (e.g. the reference template andociErrors), so they've stayed in the validate package.I've also expanded
NewErrorto take an explicit version (as requested here). That allows us to link to the proper spec even if we're capable of validating several spec versions (e.g. 1.0 and 1.1 configurations or runtimes).