Discussion: Source Provenance Attribute's allowed types

Open
#2,106 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
python
Domain
build-system

Research direction

Start by reviewing the source provenance implementation introduced in #2099 and the bst show handling mentioned here. Compare the proposed approaches for arrays, user-defined field types, and no type checking against the SPDX externalRefs and attributionTexts examples. Done means a decided, generic type-handling design with its expected configuration and behavior documented.

Written by the indexing model from the issue text.

Description

enhancement

Generic source provenance, introduced in #2099, only allows support for singular string values. When considering applying source provenance for SPDX, fields such as externalRefes and attributionTexts should be arrays. In general more type support, even just arrays would be useful, we don't want to solely cater to SPDX.

BuildStream can't itself restrict types and not care about the attributes themselves without either:

  • Accepting everything as lists, strings are a single item
  • Allowing for user definition of types per field

The former approach is simpler and works but offers no guarantee of correctness and is inaccurate for most cases whilst also tying BuildStream up in specifics instead of being generic. The latter approach is as accurate as users are but at the cost of a more complex implementation and verbose configs (not necessarily a bad thing other than to set up).

There is also the option to simply not type check source provenance attributes at all but this would add more complexity to code such as bst show to potentially need to handle literally anything.

Dominant language
Python
Stars
144
Forks
45
Avg merge
20h 38m
Merged PRs (30d)
6

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/buildstream

All issues in apache/buildstream

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.