Type checking focused around element.py and shell testing by nathanwilliams-ct · Pull Request #2167 · apache/buildstream

nathanwilliams-ct · 2026-08-11T13:56:07Z

Note: This adds a number of assertions where nullable values were assumed to be populated.

There should not be any functional changes.

richardmaw-codethink

I was curious and had some comments while reading through, hope you don't mind.

richardmaw-codethink · 2026-08-11T14:41:36Z


 # A list of all loaded loaders for this project
- self._collect = []
+ self._collect: list["Loader"] = []


https://docs.python.org/3/library/__future__.html#future__.annotations is the typical solution recommended for circular definitions
but honestly it's due to become the default in the next release and the import deprecated to eventually become a syntax error so switching to it is going to cause more work down the line

I went with the Manual String annotations as that is what is used elsewhere in the codebase at the moment.
Rabbit hole of documentation:
https://docs.python.org/3/library/__future__.html#future__.annotations
https://docs.python.org/3/reference/compound_stmts.html#annotations
https://peps.python.org/pep-0749/
https://docs.python.org/3/library/annotationlib.html#module-annotationlib
Which summarises to:
For 3.14 annotations will be lazily evaluated.
from __future__ import annotations sticks around until 3.13 reaches end of life.
from __future__ import annotations has been around since 3.7
Buildstream currently supports the following python versions: 310,311,312,313,314
Using from __future__ import annotations would mean a simple find and replace could remove it in future. Using manual quotes like this would be a lot of manual re-work..
I think I will switch to from __future__ import annotations for this PR to reduce future work...?

We don't want to rely on from __future__ import annotations since it's going away, but if the code can be made to work with it for python < 3.14, and with the native lazy annotations support in python 3.14, then it should be fine. We can import it conditionally.
But let's please try to keep changes to a minimum. If you want to do this, please do it separately.

richardmaw-codethink · 2026-08-11T14:58:38Z


 element = Element._new_from_load_element(load_element)

+ from ..plugins.elements.junction import JunctionElement


Is this deferred import intentional? It's not going to have the problem of deferring finding import problems since Element._new_from_load_element will have needed to import it, but it does seem out of place.

It's a cyclic import as JunctionElement imports Element already.
I am not a big fan of the cast here, but I am not sure on better way to do it with python's type checking. The cast is mainly to keep the type checker happy, and I am unsure if it's 'free' at runtime and makes the import unnecessary. I did debate wrapping it behind a if TYPE_CHECKING gate.
An assert isinstance(element,JunctionElement) also didn't play nice, as Element is it's base class.
I was trying to work out how I might get _new_from_load_element to just return a JunctionElement.

Note: This adds a number of assertions where nullable values were assumed to be populated.

This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct · 2026-08-11T13:56:07Z

Note: This adds a number of assertions where nullable values were assumed to be populated.

There should not be any functional changes.

richardmaw-codethink

I was curious and had some comments while reading through, hope you don't mind.

richardmaw-codethink · 2026-08-11T14:41:36Z


 # A list of all loaded loaders for this project
- self._collect = []
+ self._collect: list["Loader"] = []


https://docs.python.org/3/library/__future__.html#future__.annotations is the typical solution recommended for circular definitions
but honestly it's due to become the default in the next release and the import deprecated to eventually become a syntax error so switching to it is going to cause more work down the line

I went with the Manual String annotations as that is what is used elsewhere in the codebase at the moment.
Rabbit hole of documentation:
https://docs.python.org/3/library/__future__.html#future__.annotations
https://docs.python.org/3/reference/compound_stmts.html#annotations
https://peps.python.org/pep-0749/
https://docs.python.org/3/library/annotationlib.html#module-annotationlib
Which summarises to:
For 3.14 annotations will be lazily evaluated.
from __future__ import annotations sticks around until 3.13 reaches end of life.
from __future__ import annotations has been around since 3.7
Buildstream currently supports the following python versions: 310,311,312,313,314
Using from __future__ import annotations would mean a simple find and replace could remove it in future. Using manual quotes like this would be a lot of manual re-work..
I think I will switch to from __future__ import annotations for this PR to reduce future work...?

We don't want to rely on from __future__ import annotations since it's going away, but if the code can be made to work with it for python < 3.14, and with the native lazy annotations support in python 3.14, then it should be fine. We can import it conditionally.
But let's please try to keep changes to a minimum. If you want to do this, please do it separately.

richardmaw-codethink · 2026-08-11T14:58:38Z


 element = Element._new_from_load_element(load_element)

+ from ..plugins.elements.junction import JunctionElement


Is this deferred import intentional? It's not going to have the problem of deferring finding import problems since Element._new_from_load_element will have needed to import it, but it does seem out of place.

It's a cyclic import as JunctionElement imports Element already.
I am not a big fan of the cast here, but I am not sure on better way to do it with python's type checking. The cast is mainly to keep the type checker happy, and I am unsure if it's 'free' at runtime and makes the import unnecessary. I did debate wrapping it behind a if TYPE_CHECKING gate.
An assert isinstance(element,JunctionElement) also didn't play nice, as Element is it's base class.
I was trying to work out how I might get _new_from_load_element to just return a JunctionElement.

Note: This adds a number of assertions where nullable values were assumed to be populated.

This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct · 2026-08-11T13:56:07Z

Note: This adds a number of assertions where nullable values were assumed to be populated.

There should not be any functional changes.

richardmaw-codethink

I was curious and had some comments while reading through, hope you don't mind.

richardmaw-codethink · 2026-08-11T14:41:36Z


 # A list of all loaded loaders for this project
- self._collect = []
+ self._collect: list["Loader"] = []


https://docs.python.org/3/library/__future__.html#future__.annotations is the typical solution recommended for circular definitions
but honestly it's due to become the default in the next release and the import deprecated to eventually become a syntax error so switching to it is going to cause more work down the line

I went with the Manual String annotations as that is what is used elsewhere in the codebase at the moment.
Rabbit hole of documentation:
https://docs.python.org/3/library/__future__.html#future__.annotations
https://docs.python.org/3/reference/compound_stmts.html#annotations
https://peps.python.org/pep-0749/
https://docs.python.org/3/library/annotationlib.html#module-annotationlib
Which summarises to:
For 3.14 annotations will be lazily evaluated.
from __future__ import annotations sticks around until 3.13 reaches end of life.
from __future__ import annotations has been around since 3.7
Buildstream currently supports the following python versions: 310,311,312,313,314
Using from __future__ import annotations would mean a simple find and replace could remove it in future. Using manual quotes like this would be a lot of manual re-work..
I think I will switch to from __future__ import annotations for this PR to reduce future work...?

We don't want to rely on from __future__ import annotations since it's going away, but if the code can be made to work with it for python < 3.14, and with the native lazy annotations support in python 3.14, then it should be fine. We can import it conditionally.
But let's please try to keep changes to a minimum. If you want to do this, please do it separately.

richardmaw-codethink · 2026-08-11T14:58:38Z


 element = Element._new_from_load_element(load_element)

+ from ..plugins.elements.junction import JunctionElement


Is this deferred import intentional? It's not going to have the problem of deferring finding import problems since Element._new_from_load_element will have needed to import it, but it does seem out of place.

It's a cyclic import as JunctionElement imports Element already.
I am not a big fan of the cast here, but I am not sure on better way to do it with python's type checking. The cast is mainly to keep the type checker happy, and I am unsure if it's 'free' at runtime and makes the import unnecessary. I did debate wrapping it behind a if TYPE_CHECKING gate.
An assert isinstance(element,JunctionElement) also didn't play nice, as Element is it's base class.
I was trying to work out how I might get _new_from_load_element to just return a JunctionElement.

Note: This adds a number of assertions where nullable values were assumed to be populated.

This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct · 2026-08-11T13:56:07Z

Note: This adds a number of assertions where nullable values were assumed to be populated.

There should not be any functional changes.

richardmaw-codethink

I was curious and had some comments while reading through, hope you don't mind.

richardmaw-codethink · 2026-08-11T14:41:36Z


 # A list of all loaded loaders for this project
- self._collect = []
+ self._collect: list["Loader"] = []


https://docs.python.org/3/library/__future__.html#future__.annotations is the typical solution recommended for circular definitions
but honestly it's due to become the default in the next release and the import deprecated to eventually become a syntax error so switching to it is going to cause more work down the line

I went with the Manual String annotations as that is what is used elsewhere in the codebase at the moment.
Rabbit hole of documentation:
https://docs.python.org/3/library/__future__.html#future__.annotations
https://docs.python.org/3/reference/compound_stmts.html#annotations
https://peps.python.org/pep-0749/
https://docs.python.org/3/library/annotationlib.html#module-annotationlib
Which summarises to:
For 3.14 annotations will be lazily evaluated.
from __future__ import annotations sticks around until 3.13 reaches end of life.
from __future__ import annotations has been around since 3.7
Buildstream currently supports the following python versions: 310,311,312,313,314
Using from __future__ import annotations would mean a simple find and replace could remove it in future. Using manual quotes like this would be a lot of manual re-work..
I think I will switch to from __future__ import annotations for this PR to reduce future work...?

We don't want to rely on from __future__ import annotations since it's going away, but if the code can be made to work with it for python < 3.14, and with the native lazy annotations support in python 3.14, then it should be fine. We can import it conditionally.
But let's please try to keep changes to a minimum. If you want to do this, please do it separately.

richardmaw-codethink · 2026-08-11T14:58:38Z


 element = Element._new_from_load_element(load_element)

+ from ..plugins.elements.junction import JunctionElement


Is this deferred import intentional? It's not going to have the problem of deferring finding import problems since Element._new_from_load_element will have needed to import it, but it does seem out of place.

It's a cyclic import as JunctionElement imports Element already.
I am not a big fan of the cast here, but I am not sure on better way to do it with python's type checking. The cast is mainly to keep the type checker happy, and I am unsure if it's 'free' at runtime and makes the import unnecessary. I did debate wrapping it behind a if TYPE_CHECKING gate.
An assert isinstance(element,JunctionElement) also didn't play nice, as Element is it's base class.
I was trying to work out how I might get _new_from_load_element to just return a JunctionElement.

Note: This adds a number of assertions where nullable values were assumed to be populated.

This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct · 2026-08-11T13:56:07Z

Note: This adds a number of assertions where nullable values were assumed to be populated.

There should not be any functional changes.

richardmaw-codethink

I was curious and had some comments while reading through, hope you don't mind.

richardmaw-codethink · 2026-08-11T14:41:36Z


 # A list of all loaded loaders for this project
- self._collect = []
+ self._collect: list["Loader"] = []


https://docs.python.org/3/library/__future__.html#future__.annotations is the typical solution recommended for circular definitions
but honestly it's due to become the default in the next release and the import deprecated to eventually become a syntax error so switching to it is going to cause more work down the line

I went with the Manual String annotations as that is what is used elsewhere in the codebase at the moment.
Rabbit hole of documentation:
https://docs.python.org/3/library/__future__.html#future__.annotations
https://docs.python.org/3/reference/compound_stmts.html#annotations
https://peps.python.org/pep-0749/
https://docs.python.org/3/library/annotationlib.html#module-annotationlib
Which summarises to:
For 3.14 annotations will be lazily evaluated.
from __future__ import annotations sticks around until 3.13 reaches end of life.
from __future__ import annotations has been around since 3.7
Buildstream currently supports the following python versions: 310,311,312,313,314
Using from __future__ import annotations would mean a simple find and replace could remove it in future. Using manual quotes like this would be a lot of manual re-work..
I think I will switch to from __future__ import annotations for this PR to reduce future work...?

We don't want to rely on from __future__ import annotations since it's going away, but if the code can be made to work with it for python < 3.14, and with the native lazy annotations support in python 3.14, then it should be fine. We can import it conditionally.
But let's please try to keep changes to a minimum. If you want to do this, please do it separately.

richardmaw-codethink · 2026-08-11T14:58:38Z


 element = Element._new_from_load_element(load_element)

+ from ..plugins.elements.junction import JunctionElement


Is this deferred import intentional? It's not going to have the problem of deferring finding import problems since Element._new_from_load_element will have needed to import it, but it does seem out of place.

It's a cyclic import as JunctionElement imports Element already.
I am not a big fan of the cast here, but I am not sure on better way to do it with python's type checking. The cast is mainly to keep the type checker happy, and I am unsure if it's 'free' at runtime and makes the import unnecessary. I did debate wrapping it behind a if TYPE_CHECKING gate.
An assert isinstance(element,JunctionElement) also didn't play nice, as Element is it's base class.
I was trying to work out how I might get _new_from_load_element to just return a JunctionElement.

Note: This adds a number of assertions where nullable values were assumed to be populated.

This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct · 2026-08-11T13:56:07Z

Note: This adds a number of assertions where nullable values were assumed to be populated.

There should not be any functional changes.

richardmaw-codethink

I was curious and had some comments while reading through, hope you don't mind.

richardmaw-codethink · 2026-08-11T14:41:36Z


 # A list of all loaded loaders for this project
- self._collect = []
+ self._collect: list["Loader"] = []


https://docs.python.org/3/library/__future__.html#future__.annotations is the typical solution recommended for circular definitions
but honestly it's due to become the default in the next release and the import deprecated to eventually become a syntax error so switching to it is going to cause more work down the line

I went with the Manual String annotations as that is what is used elsewhere in the codebase at the moment.
Rabbit hole of documentation:
https://docs.python.org/3/library/__future__.html#future__.annotations
https://docs.python.org/3/reference/compound_stmts.html#annotations
https://peps.python.org/pep-0749/
https://docs.python.org/3/library/annotationlib.html#module-annotationlib
Which summarises to:
For 3.14 annotations will be lazily evaluated.
from __future__ import annotations sticks around until 3.13 reaches end of life.
from __future__ import annotations has been around since 3.7
Buildstream currently supports the following python versions: 310,311,312,313,314
Using from __future__ import annotations would mean a simple find and replace could remove it in future. Using manual quotes like this would be a lot of manual re-work..
I think I will switch to from __future__ import annotations for this PR to reduce future work...?

We don't want to rely on from __future__ import annotations since it's going away, but if the code can be made to work with it for python < 3.14, and with the native lazy annotations support in python 3.14, then it should be fine. We can import it conditionally.
But let's please try to keep changes to a minimum. If you want to do this, please do it separately.

richardmaw-codethink · 2026-08-11T14:58:38Z


 element = Element._new_from_load_element(load_element)

+ from ..plugins.elements.junction import JunctionElement


Is this deferred import intentional? It's not going to have the problem of deferring finding import problems since Element._new_from_load_element will have needed to import it, but it does seem out of place.

It's a cyclic import as JunctionElement imports Element already.
I am not a big fan of the cast here, but I am not sure on better way to do it with python's type checking. The cast is mainly to keep the type checker happy, and I am unsure if it's 'free' at runtime and makes the import unnecessary. I did debate wrapping it behind a if TYPE_CHECKING gate.
An assert isinstance(element,JunctionElement) also didn't play nice, as Element is it's base class.
I was trying to work out how I might get _new_from_load_element to just return a JunctionElement.

Note: This adds a number of assertions where nullable values were assumed to be populated.

This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct · 2026-08-11T13:56:07Z

Note: This adds a number of assertions where nullable values were assumed to be populated.

There should not be any functional changes.

richardmaw-codethink

I was curious and had some comments while reading through, hope you don't mind.

richardmaw-codethink · 2026-08-11T14:41:36Z


 # A list of all loaded loaders for this project
- self._collect = []
+ self._collect: list["Loader"] = []


https://docs.python.org/3/library/__future__.html#future__.annotations is the typical solution recommended for circular definitions
but honestly it's due to become the default in the next release and the import deprecated to eventually become a syntax error so switching to it is going to cause more work down the line

I went with the Manual String annotations as that is what is used elsewhere in the codebase at the moment.
Rabbit hole of documentation:
https://docs.python.org/3/library/__future__.html#future__.annotations
https://docs.python.org/3/reference/compound_stmts.html#annotations
https://peps.python.org/pep-0749/
https://docs.python.org/3/library/annotationlib.html#module-annotationlib
Which summarises to:
For 3.14 annotations will be lazily evaluated.
from __future__ import annotations sticks around until 3.13 reaches end of life.
from __future__ import annotations has been around since 3.7
Buildstream currently supports the following python versions: 310,311,312,313,314
Using from __future__ import annotations would mean a simple find and replace could remove it in future. Using manual quotes like this would be a lot of manual re-work..
I think I will switch to from __future__ import annotations for this PR to reduce future work...?

We don't want to rely on from __future__ import annotations since it's going away, but if the code can be made to work with it for python < 3.14, and with the native lazy annotations support in python 3.14, then it should be fine. We can import it conditionally.
But let's please try to keep changes to a minimum. If you want to do this, please do it separately.

richardmaw-codethink · 2026-08-11T14:58:38Z


 element = Element._new_from_load_element(load_element)

+ from ..plugins.elements.junction import JunctionElement


Is this deferred import intentional? It's not going to have the problem of deferring finding import problems since Element._new_from_load_element will have needed to import it, but it does seem out of place.

It's a cyclic import as JunctionElement imports Element already.
I am not a big fan of the cast here, but I am not sure on better way to do it with python's type checking. The cast is mainly to keep the type checker happy, and I am unsure if it's 'free' at runtime and makes the import unnecessary. I did debate wrapping it behind a if TYPE_CHECKING gate.
An assert isinstance(element,JunctionElement) also didn't play nice, as Element is it's base class.
I was trying to work out how I might get _new_from_load_element to just return a JunctionElement.

Note: This adds a number of assertions where nullable values were assumed to be populated.

This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct · 2026-08-11T13:56:07Z

Note: This adds a number of assertions where nullable values were assumed to be populated.

There should not be any functional changes.

richardmaw-codethink

I was curious and had some comments while reading through, hope you don't mind.

richardmaw-codethink · 2026-08-11T14:41:36Z


 # A list of all loaded loaders for this project
- self._collect = []
+ self._collect: list["Loader"] = []


https://docs.python.org/3/library/__future__.html#future__.annotations is the typical solution recommended for circular definitions
but honestly it's due to become the default in the next release and the import deprecated to eventually become a syntax error so switching to it is going to cause more work down the line

I went with the Manual String annotations as that is what is used elsewhere in the codebase at the moment.
Rabbit hole of documentation:
https://docs.python.org/3/library/__future__.html#future__.annotations
https://docs.python.org/3/reference/compound_stmts.html#annotations
https://peps.python.org/pep-0749/
https://docs.python.org/3/library/annotationlib.html#module-annotationlib
Which summarises to:
For 3.14 annotations will be lazily evaluated.
from __future__ import annotations sticks around until 3.13 reaches end of life.
from __future__ import annotations has been around since 3.7
Buildstream currently supports the following python versions: 310,311,312,313,314
Using from __future__ import annotations would mean a simple find and replace could remove it in future. Using manual quotes like this would be a lot of manual re-work..
I think I will switch to from __future__ import annotations for this PR to reduce future work...?

We don't want to rely on from __future__ import annotations since it's going away, but if the code can be made to work with it for python < 3.14, and with the native lazy annotations support in python 3.14, then it should be fine. We can import it conditionally.
But let's please try to keep changes to a minimum. If you want to do this, please do it separately.

richardmaw-codethink · 2026-08-11T14:58:38Z


 element = Element._new_from_load_element(load_element)

+ from ..plugins.elements.junction import JunctionElement


Is this deferred import intentional? It's not going to have the problem of deferring finding import problems since Element._new_from_load_element will have needed to import it, but it does seem out of place.

It's a cyclic import as JunctionElement imports Element already.
I am not a big fan of the cast here, but I am not sure on better way to do it with python's type checking. The cast is mainly to keep the type checker happy, and I am unsure if it's 'free' at runtime and makes the import unnecessary. I did debate wrapping it behind a if TYPE_CHECKING gate.
An assert isinstance(element,JunctionElement) also didn't play nice, as Element is it's base class.
I was trying to work out how I might get _new_from_load_element to just return a JunctionElement.

Note: This adds a number of assertions where nullable values were assumed to be populated.

This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct requested review from BenjaminSchubert, abderrahim, cs-shadow, gtristan and juergbi as code owners August 11, 2026 13:56

richardmaw-codethink reviewed Aug 11, 2026
View reviewed changes

nathanwilliams-ct added 2 commits August 12, 2026 11:50

Type checking focused around element.py and shell testing
047a2a6
Note: This adds a number of assertions where nullable values were assumed to be populated.

Further type checking on calculate cache key
d77f548

nathanwilliams-ct force-pushed the nathan/type-checking branch 2 times, most recently from 2372be3 to 2dd5296Compare August 12, 2026 12:25

Refactor _calculate_cache_key
c3369b7
This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct force-pushed the nathan/type-checking branch from 2dd5296 to c3369b7Compare August 12, 2026 14:13

nathanwilliams-ct commented Aug 13, 2026
View reviewed changes

Comment threadsrc/buildstream/element.py

FIXUP
fa2f28b

nathanwilliams-ct mentioned this pull request Sep 1, 2026
Shell API and CLI: Add option for staging additional runtime targets #2147
Open

nathanwilliams-ct requested review from BenjaminSchubert, abderrahim, cs-shadow, gtristan and juergbi as code owners August 11, 2026 13:56

richardmaw-codethink reviewed Aug 11, 2026
View reviewed changes

nathanwilliams-ct added 2 commits August 12, 2026 11:50

Type checking focused around element.py and shell testing
047a2a6
Note: This adds a number of assertions where nullable values were assumed to be populated.

Further type checking on calculate cache key
d77f548

nathanwilliams-ct force-pushed the nathan/type-checking branch 2 times, most recently from 2372be3 to 2dd5296Compare August 12, 2026 12:25

Refactor _calculate_cache_key
c3369b7
This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct force-pushed the nathan/type-checking branch from 2dd5296 to c3369b7Compare August 12, 2026 14:13

nathanwilliams-ct commented Aug 13, 2026
View reviewed changes

Comment threadsrc/buildstream/element.py

FIXUP
fa2f28b

nathanwilliams-ct mentioned this pull request Sep 1, 2026
Shell API and CLI: Add option for staging additional runtime targets #2147
Open

nathanwilliams-ct requested review from BenjaminSchubert, abderrahim, cs-shadow, gtristan and juergbi as code owners August 11, 2026 13:56

richardmaw-codethink reviewed Aug 11, 2026
View reviewed changes

nathanwilliams-ct added 2 commits August 12, 2026 11:50

Type checking focused around element.py and shell testing
047a2a6
Note: This adds a number of assertions where nullable values were assumed to be populated.

Further type checking on calculate cache key
d77f548

nathanwilliams-ct force-pushed the nathan/type-checking branch 2 times, most recently from 2372be3 to 2dd5296Compare August 12, 2026 12:25

Refactor _calculate_cache_key
c3369b7
This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct force-pushed the nathan/type-checking branch from 2dd5296 to c3369b7Compare August 12, 2026 14:13

nathanwilliams-ct commented Aug 13, 2026
View reviewed changes

Comment threadsrc/buildstream/element.py

FIXUP
fa2f28b

nathanwilliams-ct mentioned this pull request Sep 1, 2026
Shell API and CLI: Add option for staging additional runtime targets #2147
Open

nathanwilliams-ct requested review from BenjaminSchubert, abderrahim, cs-shadow, gtristan and juergbi as code owners August 11, 2026 13:56

richardmaw-codethink reviewed Aug 11, 2026
View reviewed changes

nathanwilliams-ct added 2 commits August 12, 2026 11:50

Type checking focused around element.py and shell testing
047a2a6
Note: This adds a number of assertions where nullable values were assumed to be populated.

Further type checking on calculate cache key
d77f548

nathanwilliams-ct force-pushed the nathan/type-checking branch 2 times, most recently from 2372be3 to 2dd5296Compare August 12, 2026 12:25

Refactor _calculate_cache_key
c3369b7
This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct force-pushed the nathan/type-checking branch from 2dd5296 to c3369b7Compare August 12, 2026 14:13

nathanwilliams-ct commented Aug 13, 2026
View reviewed changes

Comment threadsrc/buildstream/element.py

FIXUP
fa2f28b

nathanwilliams-ct mentioned this pull request Sep 1, 2026
Shell API and CLI: Add option for staging additional runtime targets #2147
Open

nathanwilliams-ct requested review from BenjaminSchubert, abderrahim, cs-shadow, gtristan and juergbi as code owners August 11, 2026 13:56

richardmaw-codethink reviewed Aug 11, 2026
View reviewed changes

nathanwilliams-ct added 2 commits August 12, 2026 11:50

Type checking focused around element.py and shell testing
047a2a6
Note: This adds a number of assertions where nullable values were assumed to be populated.

Further type checking on calculate cache key
d77f548

nathanwilliams-ct force-pushed the nathan/type-checking branch 2 times, most recently from 2372be3 to 2dd5296Compare August 12, 2026 12:25

Refactor _calculate_cache_key
c3369b7
This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct force-pushed the nathan/type-checking branch from 2dd5296 to c3369b7Compare August 12, 2026 14:13

nathanwilliams-ct commented Aug 13, 2026
View reviewed changes

Comment threadsrc/buildstream/element.py

FIXUP
fa2f28b

nathanwilliams-ct mentioned this pull request Sep 1, 2026
Shell API and CLI: Add option for staging additional runtime targets #2147
Open

nathanwilliams-ct requested review from BenjaminSchubert, abderrahim, cs-shadow, gtristan and juergbi as code owners August 11, 2026 13:56

richardmaw-codethink reviewed Aug 11, 2026
View reviewed changes

nathanwilliams-ct added 2 commits August 12, 2026 11:50

Type checking focused around element.py and shell testing
047a2a6
Note: This adds a number of assertions where nullable values were assumed to be populated.

Further type checking on calculate cache key
d77f548

nathanwilliams-ct force-pushed the nathan/type-checking branch 2 times, most recently from 2372be3 to 2dd5296Compare August 12, 2026 12:25

Refactor _calculate_cache_key
c3369b7
This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct force-pushed the nathan/type-checking branch from 2dd5296 to c3369b7Compare August 12, 2026 14:13

nathanwilliams-ct commented Aug 13, 2026
View reviewed changes

Comment threadsrc/buildstream/element.py

FIXUP
fa2f28b

nathanwilliams-ct mentioned this pull request Sep 1, 2026
Shell API and CLI: Add option for staging additional runtime targets #2147
Open

nathanwilliams-ct requested review from BenjaminSchubert, abderrahim, cs-shadow, gtristan and juergbi as code owners August 11, 2026 13:56

richardmaw-codethink reviewed Aug 11, 2026
View reviewed changes

nathanwilliams-ct added 2 commits August 12, 2026 11:50

Type checking focused around element.py and shell testing
047a2a6
Note: This adds a number of assertions where nullable values were assumed to be populated.

Further type checking on calculate cache key
d77f548

nathanwilliams-ct force-pushed the nathan/type-checking branch 2 times, most recently from 2372be3 to 2dd5296Compare August 12, 2026 12:25

Refactor _calculate_cache_key
c3369b7
This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct force-pushed the nathan/type-checking branch from 2dd5296 to c3369b7Compare August 12, 2026 14:13

nathanwilliams-ct commented Aug 13, 2026
View reviewed changes

Comment threadsrc/buildstream/element.py

FIXUP
fa2f28b

nathanwilliams-ct mentioned this pull request Sep 1, 2026
Shell API and CLI: Add option for staging additional runtime targets #2147
Open

nathanwilliams-ct requested review from BenjaminSchubert, abderrahim, cs-shadow, gtristan and juergbi as code owners August 11, 2026 13:56

richardmaw-codethink reviewed Aug 11, 2026
View reviewed changes

nathanwilliams-ct added 2 commits August 12, 2026 11:50

Type checking focused around element.py and shell testing
047a2a6
Note: This adds a number of assertions where nullable values were assumed to be populated.

Further type checking on calculate cache key
d77f548

nathanwilliams-ct force-pushed the nathan/type-checking branch 2 times, most recently from 2372be3 to 2dd5296Compare August 12, 2026 12:25

Refactor _calculate_cache_key
c3369b7
This removes the ambiguity around the type of the dependencies argument the function used

nathanwilliams-ct force-pushed the nathan/type-checking branch from 2dd5296 to c3369b7Compare August 12, 2026 14:13

nathanwilliams-ct commented Aug 13, 2026
View reviewed changes

Comment threadsrc/buildstream/element.py

FIXUP
fa2f28b

nathanwilliams-ct mentioned this pull request Sep 1, 2026
Shell API and CLI: Add option for staging additional runtime targets #2147
Open


		element = Element._new_from_load_element(load_element)

		from ..plugins.elements.junction import JunctionElement

Uh oh!

Conversation

nathanwilliams-ct commented Aug 11, 2026

Uh oh!

richardmaw-codethink left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

nathanwilliams-ct commented Aug 11, 2026

Uh oh!

richardmaw-codethink left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

nathanwilliams-ct commented Aug 11, 2026

Uh oh!

richardmaw-codethink left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment