Record where curations came from #5668
Assignees
Labels
Comments
sschuberth
added
enhancement
fviernau
added a commit
that referenced
this issue
Jan 27, 2023
The `OrtResult` does not store the uncurated packages as part of the analyzer result, but only the curated packages along with the applied package curation data. This tightly couples the curations with the analyzer without need, because the analyzer does not need (to consume) any curations at all. Also, computing the respective uncurated package from each curated package is not always possible due to missing data [1]. So, curations currently cannot properly be (re-applied) without re-running the analyzer [2]. Furthermore, the current representation stores package curation data redundantly in case the curation applies to multiple packages. Given that, it makes sense to store the curations separately from the uncurated package. So, utilize the new toplevel `resolvedConfiguration` to store the package curations and change the analyzer result to contain uncurated instead of curated packages. Note that this partially implements [1] and [2]. Adjusting the logic which turns curated into uncurated packages, e.g. `toUncuratedPackage()`, is left for a future change to limit the size of this change. Apart from that [3] can be implemented by relatively easily without redundantly encoding the provider (for each curation data). [1] #5637 [2] #6188 [3] #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Jan 27, 2023
The `OrtResult` does not store the uncurated packages as part of the analyzer result, but only the curated packages along with the applied package curation data. This tightly couples the curations with the analyzer without need, because the analyzer does not need (to consume) any curations at all. Also, computing the respective uncurated package from each curated package is not always possible due to missing data [1]. So, curations currently cannot properly be (re-applied) without re-running the analyzer [2]. Furthermore, the current representation stores package curation data redundantly in case the curation applies to multiple packages. Given that, it makes sense to store the curations separately from the uncurated package. So, utilize the new toplevel `resolvedConfiguration` to store the package curations and change the analyzer result to contain uncurated instead of curated packages. Note that this partially implements [1] and [2]. Adjusting the logic which turns curated into uncurated packages, e.g. `toUncuratedPackage()`, is left for a future change to limit the size of this change. Apart from that [3] can be implemented by relatively easily without redundantly encoding the provider (for each curation data). [1] #5637 [2] #6188 [3] #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Jan 27, 2023
The `OrtResult` does not store the uncurated packages as part of the analyzer result, but only the curated packages along with the applied package curation data. This tightly couples the curations with the analyzer without need, because the analyzer does not need (to consume) any curations at all. Also, computing the respective uncurated package from each curated package is not always possible due to missing data [1]. So, curations currently cannot properly be (re-applied) without re-running the analyzer [2]. Furthermore, the current representation stores package curation data redundantly in case the curation applies to multiple packages. Given that, it makes sense to store the curations separately from the uncurated package. So, utilize the new toplevel `resolvedConfiguration` to store the package curations and change the analyzer result to contain uncurated instead of curated packages. Note that this partially implements [1] and [2]. Adjusting the logic which turns curated into uncurated packages, e.g. `toUncuratedPackage()`, is left for a future change to limit the size of this change. Apart from that [3] can be implemented by relatively easily without redundantly encoding the provider (for each curation data). [1] #5637 [2] #6188 [3] #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Jan 27, 2023
The `OrtResult` does not store the uncurated packages as part of the analyzer result, but only the curated packages along with the applied package curation data. This tightly couples the curations with the analyzer without need, because the analyzer does not need (to consume) any curations at all. Also, computing the respective uncurated package from each curated package is not always possible due to missing data [1]. So, curations currently cannot properly be (re-applied) without re-running the analyzer [2]. Furthermore, the current representation stores package curation data redundantly in case the curation applies to multiple packages. Given that, it makes sense to store the curations separately from the uncurated package. So, utilize the new toplevel `resolvedConfiguration` to store the package curations and change the analyzer result to contain uncurated instead of curated packages. Note that this partially implements [1] and [2]. Adjusting the logic which turns curated into uncurated packages, e.g. `toUncuratedPackage()`, is left for a future change to limit the size of this change. Apart from that [3] can be implemented by relatively easily without redundantly encoding the provider (for each curation data). [1] #5637 [2] #6188 [3] #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Jan 30, 2023
The `OrtResult` does not store the uncurated packages as part of the analyzer result, but only the curated packages along with the applied package curation data. This tightly couples the curations with the analyzer without need, because the analyzer does not need (to consume) any curations at all. Also, computing the respective uncurated package from each curated package is not always possible due to missing data [1]. So, curations currently cannot properly be (re-applied) without re-running the analyzer [2]. Furthermore, the current representation stores package curation data redundantly in case the curation applies to multiple packages. Given that, it makes sense to store the curations separately from the uncurated package. So, utilize the new toplevel `resolvedConfiguration` to store the package curations and change the analyzer result to contain uncurated instead of curated packages. Note that this partially implements [1] and [2]. Adjusting the logic which turns curated into uncurated packages, e.g. `toUncuratedPackage()`, is left for a future change to limit the size of this change. Apart from that [3] can be implemented by relatively easily without redundantly encoding the provider (for each curation data). [1] #5637 [2] #6188 [3] #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Jan 30, 2023
The `OrtResult` does not store the uncurated packages as part of the analyzer result, but only the curated packages along with the applied package curation data. This tightly couples the curations with the analyzer without need, because the analyzer does not need (to consume) any curations at all. Also, computing the respective uncurated package from each curated package is not always possible due to missing data [1]. So, curations currently cannot properly be (re-applied) without re-running the analyzer [2]. Furthermore, the current representation stores package curation data redundantly in case the curation applies to multiple packages. Given that, it makes sense to store the curations separately from the uncurated package. So, utilize the new toplevel `resolvedConfiguration` to store the package curations and change the analyzer result to contain uncurated instead of curated packages. Note that this partially implements [1] and [2]. Adjusting the logic which turns curated into uncurated packages, e.g. `toUncuratedPackage()`, is left for a future change to limit the size of this change. Apart from that [3] can be implemented by relatively easily without redundantly encoding the provider (for each curation data). [1] #5637 [2] #6188 [3] #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Jan 30, 2023
The `OrtResult` does not store the uncurated packages as part of the analyzer result, but only the curated packages along with the applied package curation data. This tightly couples the curations with the analyzer without need, because the analyzer does not need (to consume) any curations at all. Also, computing the respective uncurated package from each curated package is not always possible due to missing data [1]. So, curations currently cannot properly be (re-applied) without re-running the analyzer [2]. Furthermore, the current representation stores package curation data redundantly in case the curation applies to multiple packages. Given that, it makes sense to store the curations separately from the uncurated package. So, utilize the new toplevel `resolvedConfiguration` to store the package curations and change the analyzer result to contain uncurated instead of curated packages. Note that this partially implements [1] and [2]. Adjusting the logic which turns curated into uncurated packages, e.g. `toUncuratedPackage()`, is left for a future change to limit the size of this change. Apart from that [3] can be implemented by relatively easily without redundantly encoding the provider (for each curation data). [1] #5637 [2] #6188 [3] #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Jan 30, 2023
The `OrtResult` does not store the uncurated packages as part of the analyzer result, but only the curated packages along with the applied package curation data. This tightly couples the curations with the analyzer without need, because the analyzer does not need (to consume) any curations at all. Also, computing the respective uncurated package from each curated package is not always possible due to missing data [1]. So, curations currently cannot properly be (re-applied) without re-running the analyzer [2]. Furthermore, the current representation stores package curation data redundantly in case the curation applies to multiple packages. Given that, it makes sense to store the curations separately from the uncurated package. So, utilize the new toplevel `resolvedConfiguration` to store the package curations and change the analyzer result to contain uncurated instead of curated packages. Note that this partially implements [1] and [2]. Adjusting the logic which turns curated into uncurated packages, e.g. `toUncuratedPackage()`, is left for a future change to limit the size of this change. Apart from that [3] can be implemented by relatively easily without redundantly encoding the provider (for each curation data). [1] #5637 [2] #6188 [3] #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Jan 30, 2023
The `OrtResult` does not store the uncurated packages as part of the analyzer result, but only the curated packages along with the applied package curation data. This tightly couples the curations with the analyzer without need, because the analyzer does not need (to consume) any curations at all. Also, computing the respective uncurated package from each curated package is not always possible due to missing data [1]. So, curations currently cannot properly be (re-applied) without re-running the analyzer [2]. Furthermore, the current representation stores package curation data redundantly in case the curation applies to multiple packages. Given that, it makes sense to store the curations separately from the uncurated package. So, utilize the new toplevel `resolvedConfiguration` to store the package curations and change the analyzer result to contain uncurated instead of curated packages. Note that this partially implements [1] and [2]. Adjusting the logic which turns curated into uncurated packages, e.g. `toUncuratedPackage()`, is left for a future change to limit the size of this change. Apart from that [3] can be implemented by relatively easily without redundantly encoding the provider (for each curation data). [1] #5637 [2] #6188 [3] #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Jan 31, 2023
The `OrtResult` does not store the uncurated packages as part of the analyzer result, but only the curated packages along with the applied package curation data. This tightly couples the curations with the analyzer without need, because the analyzer does not need (to consume) any curations at all. Also, computing the respective uncurated package from each curated package is not always possible due to missing data [1]. So, curations currently cannot properly be (re-applied) without re-running the analyzer [2]. Furthermore, the current representation stores package curation data redundantly in case the curation applies to multiple packages. Given that, it makes sense to store the curations separately from the uncurated package. So, utilize the new toplevel `resolvedConfiguration` to store the package curations and change the analyzer result to contain uncurated instead of curated packages. Note that this partially implements [1] and [2]. Adjusting the logic which turns curated into uncurated packages, e.g. `toUncuratedPackage()`, is left for a future change to limit the size of this change. Apart from that [3] can be implemented by relatively easily without redundantly encoding the provider (for each curation data). [1] #5637 [2] #6188 [3] #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 8, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The separate `ResolvedConfiguration.provider` list is introduced to align with the idea of adding provider metadata, as outlined in [^1] and also mentioned in [^2]. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [^1] #6188 (comment) [^2]: #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 8, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The separate `ResolvedConfiguration.provider` list is introduced to align with the idea of adding provider metadata, as outlined in [^1] and also mentioned in [^2]. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [^1] #6188 (comment) [^2]: #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 8, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The separate `ResolvedConfiguration.provider` list is introduced to align with the idea of adding provider metadata, as outlined in [^1] and also mentioned in [^2]. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [^1] #6188 (comment) [^2]: #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 8, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The separate `ResolvedConfiguration.provider` list is introduced to align with the idea of adding provider metadata, as outlined in [^1] and also mentioned in [^2]. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [^1] #6188 (comment) [^2]: #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 8, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The separate `ResolvedConfiguration.provider` list is introduced to align with the idea of adding provider metadata, as outlined in [^1] and also mentioned in [^2]. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [^1] #6188 (comment) [^2]: #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 8, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The separate `ResolvedConfiguration.provider` list is introduced to align with the idea of adding provider metadata, as outlined in [^1] and also mentioned in [^2]. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [^1] #6188 (comment) [^2]: #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 13, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The separate `ResolvedConfiguration.provider` list is introduced to align with the idea of adding provider metadata, as outlined in [^1] and also mentioned in [^2]. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [^1] #6188 (comment) [^2]: #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 13, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The separate `ResolvedConfiguration.provider` list is introduced to align with the idea of adding provider metadata, as outlined in [^1] and also mentioned in [^2]. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [^1] #6188 (comment) [^2]: #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 16, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The separate `ResolvedConfiguration.provider` list is introduced to align with the idea of adding provider metadata, as outlined in [1] and also mentioned in [2]. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [1]: #6188 (comment) [2]: #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 16, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The data model is adjusted as agreed in [1], while adding `config` and `type` of the provider is left for a future change. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [1]: #6456 (comment) Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 16, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The separate `ResolvedConfiguration.provider` list is introduced to align with the idea of adding provider metadata, as outlined in [^1] and also mentioned in [^2]. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [^1] #6188 (comment) [^2]: #5668 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 16, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The data model is adjusted as agreed in [1], while adding `config` and `type` of the provider is left for a future change. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [1]: #6456 (comment) Signed-off-by: Frank Viernau <frank_viernau@epam.com>
fviernau
added a commit
that referenced
this issue
Feb 16, 2023
Extend `ResolvedConfiguration` to associate the curations with the ID of the package curation provider to enable tracability of curations back to the provider. The data model is adjusted as agreed in [1], while adding `config` and `type` of the provider is left for a future change. This implementation also is a first step towards use cases involving: 1. Replacing the curations for a given provider ID with the given ones. 2. Re-resolve curations only for a particular provider ID. Both are left as TODO for future changes to limit the size of this change, while for 1. a TODO comment is left in the code. Fixes #5668. [1]: #6456 (comment) Signed-off-by: Frank Viernau <frank_viernau@epam.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Analyzer results that contain curations should record the provider a curation originates from. Maybe just the provider's (class) name would be enough, but e.g. for
CompositePackageCurationProviderthe real underlying provider should be recorded, and e.g. forFilePackageCurationProvidermaybe some more details like the (relative) directory path would make sense.Recording the origin / source of a curation improves transparency and helps with debugging metadata issues.
The text was updated successfully, but these errors were encountered: