Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix and Apply CI Lint Checks #108

Merged
merged 13 commits into from
Oct 27, 2023
Merged

Fix and Apply CI Lint Checks #108

merged 13 commits into from
Oct 27, 2023

Conversation

mfleader
Copy link
Member

@mfleader mfleader commented Oct 26, 2023

Changes introduced with this PR

  • Fix CI checks on style and linting.
  • Apply required style formatting and linting (enforcing CI checks required this).
  • black was removed as a style format checker. At this point, it is only used to converge the code base towards flake8 acceptance.

Almost no style checks nor linting was performed on this repository until now, so this is a big one.


By contributing to this repository, I agree to the contribution guidelines.

@mfleader mfleader changed the title Fix CI Checks Fix and Apply CI Lint Checks Oct 26, 2023
@mfleader mfleader self-assigned this Oct 26, 2023
@mfleader mfleader marked this pull request as ready for review October 26, 2023 21:48
Copy link
Contributor

@jaredoconnell jaredoconnell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks good. I don't like all of the new format, but we agreed on black and flake8. I see some higher risk changes, like messing with isinstance. If those are well tested, or applied automatically, then it's fine. The CI is passing.

Copy link

@dbutenhof dbutenhof left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see some higher risk changes, like messing with isinstance.

That's an interesting point, and the answer really depends on the intent of the check.

type(a) is Foo is True only if a is actually a Foo() instance, exactly; whereas isinstance(a, Foo) is True if a is a Foo or a subclass of Foo.

I think in the context I read, the latter is more appropriate, in which case using type means that subclassing will break the tests whereas the new isinstance is resistant to that.

But of course if subclasses need not apply, then type is better... (I think that's rarely true or appropriate...)

src/arcaflow_plugin_sdk/schema.py Show resolved Hide resolved
src/arcaflow_plugin_sdk/schema.py Show resolved Hide resolved
@mfleader mfleader added the bug Something isn't working label Oct 27, 2023
@mfleader mfleader merged commit 6cbc001 into arcalot:main Oct 27, 2023
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants