Add type annotations #1761

chadrik · 2024-05-19T17:38:29Z

This is a first pass at adding type annotations throughout the code-base. Mypy is not fully passing yet, but it's getting close.

Addresses #1631

linux-foundation-easycla · 2024-05-19T17:38:33Z

The committers listed above are authorized under a signed CLA.

✅ login: chadrik / name: Chad Dombrova (ea166f5, dd86192)

chadrik · 2024-05-19T17:43:55Z

src/rez/package_filter.py

@@ -327,7 +327,7 @@ class Rule(object):
    """Base package filter rule"""

    #: Rule name
-    name = None
+    name: str


This pattern appears on abstract base classes in a number of places, and we have 3 choices:

Option 1:

name: str | None = None

typically produces many spurious mypy errors, because the code assumes the value is a string everywhere, and the None-case is not handled.

Option 2:

name: str

only safe if we're sure that the name attribute is always accessed on concrete sub-classes, otherwise will result in an AttributeError since this does not actually create an attribute.

Option 3:

@property @abstractmethod def name(self) -> str: raise NotImplementedError

Provides us some guarantee that sub-classes actually implement name, but it cannot be accessed from the class, only from an instance.

chadrik · 2024-05-19T17:45:40Z

src/rez/package_order.py

-    def __eq__(self, other):
+    def __eq__(self, other: object) -> bool:
+        if not isinstance(other, FallbackComparable):
+            return NotImplemented


mypy strongly prefers that comparison functions define the type of other as object. by returning NotImplemented python will then defer to the other object in the comparison to handle equality if it implements it. This should not change the behavior as long as other is always FallbackComparable within Rez.

Implementation comments should go in the code.

chadrik · 2024-05-19T17:47:39Z

src/rez/package_resources.py

-    pass
+
+    def iter_packages(self) -> Iterator[Package]:
+        raise NotImplementedError


All subclasses of PackageFamilyResource implement this method, so it appears to be considered an abstractmethod of PackageFamilyResource. Defining it simplifies some type annotation problems.

chadrik · 2024-05-19T17:48:10Z

src/rez/package_resources.py

+    @property
+    @abstractmethod
+    def parent(self) -> PackageRepositoryResource:
+        raise NotImplementedError


same situation here as with PackageFamilyResource.iter_packages.

chadrik · 2024-05-19T17:48:19Z

src/rez/package_resources.py

+    @property
+    @abstractmethod
+    def parent(self) -> PackageRepositoryResource:
+        raise NotImplementedError


here as well.

chadrik · 2024-05-19T17:49:24Z

src/rez/packages.py

@@ -319,6 +326,7 @@ def get_variant(self, index=None):
        for variant in self.iter_variants():
            if variant.index == index:
                return variant
+        return None


mypy prefer explicit return None statements

chadrik · 2024-05-19T17:50:06Z

src/rez/resolved_context.py

-                raise ResolvedContextError(
-                    "Cannot perform operation in a failed context")
-        return _check
-


mypy does not like these decorators defined at the class-level.

chadrik · 2024-05-19T18:08:22Z

Protocol and TypedDict are not available in the typing module until python 3.8.

We have a few options:

vendor typing_extensions
remove use of these typing classes until Rez drops support for python 3.7
I can create a mock of Protocol and trick mypy into using it which is safe because it has no runtime behavior. Doing the same thing for TypedDict is more complicated, but possible.

codecov · 2024-05-19T18:33:50Z

Codecov Report

Attention: Patch coverage is 83.19328% with 180 lines in your changes missing coverage. Please review.

Project coverage is 59.16%. Comparing base (491497f) to head (dd86192).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
src/rez/suite.py	53.33%	20 Missing and 1 partial ⚠️
src/rez/version/_version.py	88.81%	11 Missing and 7 partials ⚠️
src/rez/package_order.py	73.43%	13 Missing and 4 partials ⚠️
src/rez/resolved_context.py	75.92%	11 Missing and 2 partials ⚠️
src/rez/solver.py	94.03%	10 Missing and 3 partials ⚠️
src/rez/package_resources.py	77.55%	9 Missing and 2 partials ⚠️
src/rez/build_system.py	65.51%	9 Missing and 1 partial ⚠️
src/rez/packages.py	82.75%	9 Missing and 1 partial ⚠️
src/rez/build_process.py	75.00%	5 Missing and 2 partials ⚠️
src/rez/utils/data_utils.py	79.31%	4 Missing and 2 partials ⚠️
... and 23 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1761      +/-   ##
==========================================
- Coverage   59.30%   59.16%   -0.15%     
==========================================
  Files         126      127       +1     
  Lines       17210    17452     +242     
  Branches     3015     3049      +34     
==========================================
+ Hits        10206    10325     +119     
- Misses       6319     6408      +89     
- Partials      685      719      +34

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

chadrik · 2024-05-20T05:34:07Z

I got bored and added lots more, particularly focused on the solver module. Once the solver module is complete, we can experiment with compiling it to a c-extension using mypyc, which could provide a big speed boost!

chadrik · 2024-05-21T03:28:27Z

I now have rez.solver compiling as a C-extension with all tests passing. I'm very interested to see how the performance compares. Does anyone want to volunteer to help put together a performance comparison? Are there any known complex collection of packages to test against?

chadrik · 2024-05-21T03:37:46Z

src/rez/package_order.py

-        self.dirty = True
-        return super().append(*args, **kwargs)
+    if not TYPE_CHECKING:
+        def append(self, *args, **kwargs):


Since this class inherits from list it's easier to rely on the type hints coming from that base class than to redefine them here, so we hide them by placing them behind not TYPE_CHECKING. In reality, the runtime value of TYPE_CHECKING is always False.

chadrik · 2024-05-21T03:40:32Z

src/rez/plugin_managers.py

+    def get_plugin_class(self, plugin_type: str, plugin_name: str, expected_type: type[T]) -> type[T]:
+        pass
+
+    def get_plugin_class(self, plugin_type, plugin_name, expected_type=None):
        """Return the class registered under the given plugin name."""
        plugin = self._get_plugin_type(plugin_type)


Added a new argument here to validate the returned result. This provides both runtime and static validation.

Could plugin_type be an enum or something like that? This would remove the need for expected_type right? Or maybe we could use overloads with Literals for expected_type?

this uses type vars to describe a generic function, i.e. a function where the types of its arguments are related to each other. In our case, the type of the argument expected_type is related to the output type.

Using a literal would mean we would have to define a literal value and a function overload for every possible output type, like this:

@overload def get_plugin_class(self, plugin_type: str, plugin_name: str, expected_type: Literal["Foo"]) -> type[Foo]: pass @overload def get_plugin_class(self, plugin_type: str, plugin_name: str, expected_type: Literal["Bar"]) -> type[Bar]: pass

In a plugin environment where users can define their own types, we obviously cannot define a string constant for every possible type.

Users can't define their own types. They can only create new plugin of some pre-defined types. Anybody adding new plugin types should do so in rez itself and not outside.

chadrik · 2024-05-21T03:41:43Z

src/rez/resolved_context.py

        """Perform a package resolve, and store the result.

        Args:
-            package_requests (list[typing.Union[str, PackageRequest]]): request
+            package_requests (list[typing.Union[str, Requirement]]): request


I noticed that everywhere that we've documented types as PackageRequest, they appear to actually be Requirement. I'm not sure if there any real-world exceptions to this.

Here it's really supposed to be a PackageRequest if I'm not mistaken. But there is technically no differences between the two once the instantiated since PackageRequest inherits from Requirement and only overloads __init__ to check the inputs.

The kind of haphazard use and documentation of PackageRequest and PackageRequest results in some very difficult situations to accurately add type annotations. If you want to see for yourself, check out the code, change this to PackageRequest and observe the new errors produced by mypy.

chadrik · 2024-05-21T03:42:10Z

src/rez/resolved_context.py

@@ -884,7 +912,7 @@ def _rt(t):
            return

        _pr("resolved packages:", heading)
-        rows = []
+        rows3: list[tuple[str, str, str]] = []


you can't redefine types with mypy, so you need to use new variable names.

chadrik · 2024-05-21T03:42:54Z

src/rez/system.py

@@ -88,7 +88,7 @@ def shell(self):
                    args = ['ps', '-o', 'args=', '-p', str(parent_pid)]
                    proc = sp.Popen(args, stdout=sp.PIPE)
                    output = proc.communicate()[0]
-                    shell = os.path.basename(output.strip().split()[0]).replace('-', '')
+                    shell = os.path.basename(output.decode().strip().split()[0]).replace('-', '')


output is bytes in python3, so need to call decode()

We use text=True, so it should be string isn't it?

We didn't use text=True here. I could pass text=True to Popen.

See https://github.com/AcademySoftwareFoundation/rez/blob/main/src/rez/system.py#L89.

chadrik · 2024-05-21T03:43:31Z

src/rez/utils/data_utils.py

+if TYPE_CHECKING:
+    cached_property = property
+else:
+    class cached_property(object):


it's much easier to pretend that cached_property is property than to type hint all the subtleties of a descriptor.

But we loose the uncache method.

typing.TYPE_CHECKING always resolve to False at runtime and True only during static analysis. So the code within the if TYPE_CHECKING block will never run. It's a way to simplify certain type analysis situations that arise.

typing.TYPE_CHECKING always resolve to False

I know, but we are loosing stuff during typing. That's my whole point (the same apply to all my comments that are similar to this one).

in what way would the static analysis be degraded by using property instead of cached_property? To my knowledge, they are functionally equivalent from a static analysis POV: the types returned are the same.

chadrik · 2024-05-21T03:45:46Z

src/rez/solver.py

+        self.depth_counts: dict
+        self.solve_begun: bool
+        self.solve_time: float
+        self.load_time: float


these values are never actually None, so we define the types here, and their values are assigned in _init()

chadrik · 2024-05-21T03:48:40Z

src/rez/solver.py

@@ -74,9 +97,6 @@ class SolverStatus(Enum):
    cyclic = ("The solve contains a cycle.", )
    unsolved = ("The solve has started, but is not yet solved.", )

-    def __init__(self, description):
-        self.description = description
-


mypyc did not like adding a new __init__ for Enum, so it was simple enough to replace this attribute with a call to the enum value.

chadrik · 2024-05-21T03:49:58Z

src/rez/solver.py

        """Reset the solver, removing any current solve."""
        if not self.request_list.conflict:
-            phase = _ResolvePhase(self.request_list.requirements, solver=self)
+            phase = _ResolvePhase(solver=self)


This appears to be a bug: _ResolvePhase only takes one argument. mypy to the rescue.

chadrik · 2024-05-21T04:48:54Z

I found rez-benchmark. Interestingly, rez is slower with the compiled rez.solver. It could be because there are many modules and classes used by rez.solver which have not been compiled.

I probably won't have time to dig into this much more, but once this PR is merged I'll make a new PR with the changes necessary for people to test the compiled version of rez.

chadrik · 2024-05-21T18:27:53Z

Note: this PR likely invalidates #1745

chadrik · 2024-06-05T18:04:33Z

@instinct-vfx Can you or someone from the Rez group have a look at this, please?

JeanChristopheMorinPerso · 2024-06-22T16:46:20Z

src/rez/build_process.py

        return self.build_system.working_dir

-    def build(self, install_path=None, clean=False, install=False, variants=None):
+    def build(self, install_path: str | None = None, clean: bool = False,


Using str | None means we need to drop support for python 3.7. I'm not sure we are ready for this yet.

No, use of str | None is safe in python 3.7 as long as you use from __future__ import annotations. This backports behavior from python 3.9 that ensures that type annotations are recorded as strings within __annotations__ attributes, which means they are not evaluated at runtime unless inspect.get_annoations is called. The effect of from __future__ import annotations is that you can put basically anything you want into an annotation, it doesn't need to be valid at runtime.

The only thing breaking python 3.7 compatibility here is the use of TypedDict and Protocol, as mentioned in another comment. I presented 3 options for preserving the use of these classes in the other comment.

I noticed that the only python 3.7 tests that are currently run are for MacOS, which I took as an indicator that python 3.7 would be dropped soon. Is there a schedule for deprecation?

By the way, I fixed the python 3.7 compatibility issue with TypedDict and Protocol, so that should not be a blocker anymore.

JeanChristopheMorinPerso · 2024-06-22T16:47:01Z

@chadrik You need to sign the CLA before we can even start to look at the PR.

chadrik · 2024-06-22T19:47:27Z

@JeanChristopheMorinPerso

@chadrik You need to sign the CLA before we can even start to look at the PR.

I work for Scanline, which is owned by Netflix, and I'm meeting with our CLA manager on Monday. I made this contribution on my own time: can choose individual vs corporate CLA on a per PR basis?

JeanChristopheMorinPerso · 2024-06-22T20:28:37Z

I made this contribution on my own time: can choose individual vs corporate CLA on a per PR basis?

I don't think you "can" but your account can be associated to an an ICLA and a CCLA. But I'm not a lawyer so I can't help more than that. If you and or your employer/CLA manager have questions, you can contact the LF support by following the link in the EasyCLA comment: #1761 (comment).

chadrik · 2024-07-01T21:09:04Z

CLA is signed!

chadrik · 2024-07-01T21:15:49Z

src/rez/build_system.py

@@ -143,12 +167,12 @@ def __init__(self, working_dir, opts=None, package=None,
        self.opts = opts

    @classmethod
-    def is_valid_root(cls, path):
+    def is_valid_root(cls, path: str, package=None) -> bool:
        """Return True if this build system can build the source in path."""


sub-classes are expected to have the package argument. I think this was just an oversight on the base class.

What type should it have?

chadrik · 2024-07-01T21:21:56Z

src/rez/package_order.py

@@ -614,13 +633,13 @@ def from_pod(cls, data):
        )


-class PackageOrderList(list):
+class PackageOrderList(List[PackageOrder]):


Note that we use typing.List here instead of list because list does not become indexable at runtime until python 3.9. It's still safe to use list[X] inside annotations as long as we use from __future__ import annotations.

chadrik · 2024-07-18T14:49:11Z

Any thoughts on this PR?

JeanChristopheMorinPerso · 2024-07-21T19:49:46Z

Hey @chadrik, I made a first good read last week and I'll try to do another one soon. If you have the time, I would really love to see a GitHub Actions workflow that would run mypy on all pull requests.

chadrik · 2024-07-21T20:20:16Z

I would really love to see a GitHub Actions workflow that would run mypy on all pull requests.

Me too!

The challenge is that there are still a lot of errors. These are not the result of incorrect annotations, but rather due to code patterns which are difficult to annotate correctly without more invasion refactors. For example, there are quite a few objects which dynamically generate attributes, and that's a static typing anti-pattern.

If you'd like an Action that runs mypy but allows failure for now, that's pretty easy, but if you want failures to block PRs, that'll take a lot more work. I'd prefer not to make that a blocker to merging this, though, because I've had to rebase and fix merge conflicts a few times already.

I do have a plan for how we can get to zero failures in the mid-term: I wrote a tool which allows you to specify patterns for errors to ignore, but I need to update it.

JeanChristopheMorinPerso · 2024-07-21T20:27:18Z

I think we can introduce a workflow that will fail for newly introduced errors and warnings. I'm sure someone already thought of that somewhere and we can probably re-use what they did?

Basically, I'd like to verify that your changes work as expected and that we don't regress in the future and that new code is typed hint. Mypy can also be configured on a per module basis right?

chadrik · 2024-08-05T23:32:23Z

@JeanChristopheMorinPerso I used a project called mypy-baseline to create a set of ignore patterns that can be filtered out until they're resolved: https://mypy-baseline.orsinium.dev/usage

If new errors are introduced they will need to be resolved (i.e. errors not filtered by the established baseline regexes). The regexes are bound to particular files but not to line numbers. The mypy CI job will pass if a developer fixes an error, but in this case it is good practice to set a new baseline using mypy | mypy-baseline sync --ignore-categories=note. When creating a baseline, care must be taken to use the same version of python and mypy.

dbr · 2024-08-09T02:36:59Z

Not sure if it was discussed already, but is it feasible to only use # typing: ignore comments to suppress existing known errors?

Main benefit would be people using mypy integration in their editors wouldn't be flooded with the errors ignored by mypy-baseline

I think mypy also warns when the ignore is no longer needed, so if some refactoring resolves the issue, the comments are easy to clean up

chadrik · 2024-08-11T04:20:29Z

There are about 300 errors, so using inline ignores has the downside of littering the code with type comments. It also means that developers need to be careful to move the ignore comments to the proper locations when refactoring code, and the solution not always obvious. I think at this stage what I’ve presented here is a very low effort way to ease this project into type annotations. With the mypy-baseline project there is a simple way to just bulk add problems to the ignore list, if necessary.

FWIW, most of the remaining errors will require some pretty major refactors to resolve — meaning we probably need to replace the schema objects with something like dataclasses or pydantic to remove dynamic attribute generation. If folks are interested in taking on some more substantial changes to get the code base fully covered, I’m happy to do that.

chadrik · 2024-08-23T02:34:31Z

Shall we get this merged?

chadrik · 2024-09-11T15:56:14Z

Hi! Is there anything I can do to get this across the line?

Signed-off-by: Chad Dombrova <[email protected]>

JeanChristopheMorinPerso · 2024-10-14T22:08:24Z

Rebased to get all the latest changes from main.

JeanChristopheMorinPerso

Second batch of comments. Note that I'm not yet done with the review. Please don't push changes until I'm done.

JeanChristopheMorinPerso · 2024-10-14T22:24:08Z

src/rez/build_system.py

@@ -67,9 +89,10 @@ def get_valid_build_systems(working_dir, package=None):
    return clss


-def create_build_system(working_dir, buildsys_type=None, package=None, opts=None,
+def create_build_system(working_dir: str, buildsys_type: str | None = None,
+                        package=None, opts=None,


Suggested change

package=None, opts=None,

package: Package | None = None, opts: argparse.Namespace | None = None,

?

As mentioned in the other comment, I'd prefer for new annotations to be done in a new PR, so that we can keep the scope of this PR under control. There are literally thousands of unannotated arguments that still need to be dealt with.

From what I see, the current typing seems arbitrary. Some stuff was typed, some others don't and I'm not too sure what the logic is. I think it would be preferable to change the whole signature instead of just changing half of it since we are anyway changing it.

JeanChristopheMorinPerso · 2024-10-14T22:25:03Z

src/rez/build_system.py

        """Return the name of the build system, eg 'make'."""
        raise NotImplementedError

-    def __init__(self, working_dir, opts=None, package=None,
-                 write_build_scripts=False, verbose=False, build_args=[],
+    def __init__(self, working_dir: str, opts=None,


Suggested change

def __init__(self, working_dir: str, opts=None,

def __init__(self, working_dir: str, opts: argparse.Namespace | None = None,

?

I'd prefer for new annotations to be done in a new PR, so that we can keep the scope of this PR under control. There are literally thousands of unannotated arguments that still need to be dealt with.

JeanChristopheMorinPerso · 2024-10-14T22:28:35Z

src/rez/build_system.py

+                 write_build_scripts: bool = False, verbose: bool = False, build_args=[],
                 child_build_args=[]):


Suggested change

write_build_scripts: bool = False, verbose: bool = False, build_args=[],

child_build_args=[]):

write_build_scripts: bool = False, verbose: bool = False, build_args" Sequence[str]=[],

child_build_args: Sequence[str]=[]):

? (we could potentially do this later since we'd need to remove the default lists.

JeanChristopheMorinPerso · 2024-10-14T22:29:15Z

src/rez/build_system.py

@@ -143,12 +167,12 @@ def __init__(self, working_dir, opts=None, package=None,
        self.opts = opts

    @classmethod
-    def is_valid_root(cls, path):
+    def is_valid_root(cls, path: str, package=None) -> bool:
        """Return True if this build system can build the source in path."""


What type should it have?

JeanChristopheMorinPerso · 2024-10-14T22:57:33Z

src/rez/package_order.py

-    def __eq__(self, other):
+    def __eq__(self, other: object) -> bool:
+        if not isinstance(other, FallbackComparable):
+            return NotImplemented


Implementation comments should go in the code.

JeanChristopheMorinPerso · 2024-10-15T00:30:52Z

src/rez/utils/patching.py

@@ -42,8 +42,8 @@ def get_patched_request(requires, patchlist):
        '^': (True, True, True)
    }

-    requires = [Requirement(x) if not isinstance(x, Requirement) else x
-                for x in requires]
+    requires: list[Requirement | None] = [


Can it really contain a None?

The code below says:

for i, req in enumerate(requires): if req is None or req.name != name: continue

One way to try to find out would be to annotate the function and see if mypy detects any cases where None is passed:

def get_patched_request(requires: list[Requirement | str], patchlist):

JeanChristopheMorinPerso · 2024-10-15T00:31:38Z

src/rez/utils/platform_.py

@@ -555,7 +557,8 @@ def _difftool(self):


 # singleton
-platform_ = None
+# FIXME: is is valid for platform_ to be None?


Technically yes, say on solaris, freebsd, etc.

allowing it to be None causes tons of mypy errors because there are lots of places where platform_ is used without checking if it's None.

And to be perfectly clear, these errors indicate that there are many places with the rez code that will fail at runtime if platform_ is None.

Sure, I was just answering the question. It will fail if it's None. We could fix this by simply adding an else clause and raise a exception with a clear error message.

JeanChristopheMorinPerso · 2024-10-15T00:33:04Z

src/rez/utils/resources.py

+if TYPE_CHECKING:
+    # this is not available in typing until 3.11, but due to __future__.annotations
+    # we can use it without really importing it
+    from typing import Self


This makes it impossible to run mypy with python < 3.11 right?

no, because this is inside a if TYPE_CHECKING block.

as I explained in my other comment code within an if TYPE_CHECKING does not actually run.

Note how I said "run mypy". Like, if we were to run mypy with python_version = 3.7 for example.

JeanChristopheMorinPerso · 2024-10-15T00:37:22Z

src/rez/version/_requirement.py

            if (self.name_ != other.name_) or (self.range is None):
                return False
            if self.conflict:
                return (other.version_ in self.range_)
            else:
                return (other.version_ not in self.range_)
+        else:
+            return NotImplemented


Should this raise an NotImplementedError instead?

Nope. NotImplemented is a singleton that is used to indicate "I don't support this comparison", and python will fall back to other object's special method to see if it supports the comparison.

https://docs.python.org/3/reference/datamodel.html#object.__ge__

When no appropriate method returns any value other than NotImplemented, the == and != operators will fall back to is and is not, respectively.

This is a fundamental part of how comparison works in python, and returning NotImplemented is the most correct behavior.

But should we allow comparing with anything else than a Requirement or VersionedObject? I wouldn't consider this function a comparator per say.

JeanChristopheMorinPerso · 2024-10-15T00:39:20Z

src/rez/version/_requirement.py

        if self._str is None:
            pre_str = '~' if self.negate_ else ('!' if self.conflict_ else '')
            range_str = ''
            sep_str = ''

            range_ = self.range_
-            if self.negate_:
+            # Note: the only time that range_ is None is if self.negate_ is True
+            if self.negate_ or range_ is None:


I'm not sure this is the right thing to do. Why should range_ be None?

this is the init code:

m = self.sep_regex.search(s) if m: i = m.start() self.name_ = s[:i] req_str = s[i:] if req_str[0] in ('-', '@', '#'): self.sep_ = req_str[0] req_str = req_str[1:] self.range_ = VersionRange( req_str, invalid_bound_error=invalid_bound_error) if self.negate_: self.range_ = ~self.range_ elif self.negate_: self.name_ = s # rare case - '~foo' equates to no effect self.range_ = None else: self.name_ = s self.range_ = VersionRange()

Notice that if self.negate_ is True, self._range_ is set to None.

chadrik requested a review from a team as a code owner May 19, 2024 17:38

chadrik commented May 19, 2024

View reviewed changes

chadrik commented May 21, 2024

View reviewed changes

JeanChristopheMorinPerso added the Blocked by CLA Waiting on CLA to be signed label Jun 22, 2024

JeanChristopheMorinPerso reviewed Jun 22, 2024

View reviewed changes

chadrik force-pushed the typing branch 4 times, most recently from e73c6c1 to 961420b Compare June 22, 2024 23:10

chadrik force-pushed the typing branch from 44f4ac3 to efcae39 Compare July 1, 2024 21:07

chadrik commented Jul 1, 2024

View reviewed changes

JeanChristopheMorinPerso removed the Blocked by CLA Waiting on CLA to be signed label Jul 1, 2024

chadrik force-pushed the typing branch from 2e7fc29 to 3e61ca7 Compare August 5, 2024 23:24

chadrik added 2 commits October 14, 2024 18:07

Add type annotations

ea166f5

Signed-off-by: Chad Dombrova <[email protected]>

Add Github action to run mypy

dd86192

Signed-off-by: Chad Dombrova <[email protected]>

JeanChristopheMorinPerso force-pushed the typing branch from 3e61ca7 to dd86192 Compare October 14, 2024 22:08

JeanChristopheMorinPerso reviewed Oct 15, 2024

View reviewed changes

	package=None, opts=None,
	package: Package \| None = None, opts: argparse.Namespace \| None = None,

	def __init__(self, working_dir: str, opts=None,
	def __init__(self, working_dir: str, opts: argparse.Namespace \| None = None,

		write_build_scripts: bool = False, verbose: bool = False, build_args=[],
		child_build_args=[]):

Add type annotations #1761

Are you sure you want to change the base?

Add type annotations #1761

Conversation

chadrik commented May 19, 2024

linux-foundation-easycla bot commented May 19, 2024 • edited Loading

chadrik May 19, 2024 • edited Loading

Choose a reason for hiding this comment

Option 1:

Option 2:

Option 3:

chadrik May 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chadrik commented May 19, 2024

codecov bot commented May 19, 2024 • edited Loading

Codecov Report

chadrik commented May 20, 2024

chadrik commented May 21, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chadrik Oct 15, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chadrik commented May 21, 2024

chadrik commented May 21, 2024

chadrik commented Jun 5, 2024

Choose a reason for hiding this comment

chadrik Jun 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JeanChristopheMorinPerso commented Jun 22, 2024

chadrik commented Jun 22, 2024

JeanChristopheMorinPerso commented Jun 22, 2024

chadrik commented Jul 1, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chadrik commented Jul 18, 2024

JeanChristopheMorinPerso commented Jul 21, 2024

chadrik commented Jul 21, 2024

JeanChristopheMorinPerso commented Jul 21, 2024

chadrik commented Aug 5, 2024

dbr commented Aug 9, 2024 • edited Loading

chadrik commented Aug 11, 2024 • edited Loading

chadrik commented Aug 23, 2024

chadrik commented Sep 11, 2024

JeanChristopheMorinPerso commented Oct 14, 2024

JeanChristopheMorinPerso left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

linux-foundation-easycla bot commented May 19, 2024 •

edited

Loading

chadrik May 19, 2024 •

edited

Loading

chadrik May 19, 2024 •

edited

Loading

codecov bot commented May 19, 2024 •

edited

Loading

chadrik Oct 15, 2024 •

edited

Loading

chadrik Jun 22, 2024 •

edited

Loading

dbr commented Aug 9, 2024 •

edited

Loading

chadrik commented Aug 11, 2024 •

edited

Loading

chadrik Oct 15, 2024 •

edited

Loading