pre-commit improvements

[AlexanderViand-Intel]

This PR consists of three parts:

1. Improvements to the pre-commit setup

   • pre-commit now runs hermetically (does not require local env to be set up)
   • switched to the significantly faster (and hermetically runnable) ruff over pylint (also subsumes black formatting)
   • Various other small fixes, such as fixing BOM characters that were messing with license header insertion
   • Adds a pyproject.toml that serves as a single source of truth for both pre-commit formatting/linting as well as editors/IDEs

2. A commit recording the state of the repo after running pre-commit run --all-files (i.e., all automatic changes)

3. Manual fixes that were required to get pre-commuit run --all-files to finally pass completely.
   Note that this is just fixing the tip of the iceberg: the setup includes lots of general global exceptions to the such as relaxed naming/casing rules, and nearly the whole assembler being excepted, in order to avoid needing to change vast numbers of variable/function/class names.

Since the second commit introduces a lot of diff "noise", I suggest using the commit filter during review:

• Changes to the setup
• Manual fixes

[AlexanderViand-Intel]

The changes broke some of the tests (all fixed now ✅), specifically :

• the linter removes redundant (same as default value) arguments from calls and that tripped up pydantic and some expect_calls
• the linter strictly prefers isinstance(x, A | B | C) which broke a complex mocking setup used in the assembler tests. Instead of making the mocking even more complex, I switched to using MockMagic's spec feature so that the mock objects work with unmodified isinstance.

@joserochh I think you were the last one to touch that mocking setup, so I'd especially value your feedback on these changes

[faberga]

Hi @AlexanderViand, thanks for splitting the PRs.

Can we hold this PR to go after PR #104 ? The reason being that PR 104 updates and changes the program mapper and functional modeler README, plus file doc locations, and bring in trace files for tutorials.

Thanks

[kylanerace]

Is there a particular reason the linter prefers isinstance(x, A | B | C) (mentioned here) as opposed to isinstance(x, (A, B, C))? If I recall, this is generally a Python 3.10+ feature? Seems like it would decrease version compatibility mainly for formatting preference, or is there a separate benefit?

[AlexanderViand-Intel]

Is there a particular reason the linter prefers isinstance(x, A | B | C) (mentioned here) as opposed to isinstance(x, (A, B, C))?

Good question! I just looked up which specific rule is responsible for it (it's UP308) and it's actually slated to be deprecated already, so I think we can just ignore it globally for now! I'll push a commit to revert the changes :)

If I recall, this is generally a Python 3.10+ feature? Seems like it would decrease version compatibility mainly for formatting preference, or is there a separate benefit?

I don't think we need to worry about 3.9 support anymore - it's about to hit EOL, and Ubuntu has shipped a 3.10+ version for the last two LTS, so you'd have to be on a really outdated system for this to matter. The reason the rule was deprecated doesn't seem to be about 3.9 compatibility, but because this syntax produces slightly slower code than the old one?

[joserochh]

Thank you @AlexanderViand-Intel, I like this formatting better. And the automatic fixes were great. The only thing I see is the stacked license notes for both 2025 and 2024.

[AlexanderViand-Intel]

Thank you @AlexanderViand-Intel, I like this formatting better. And the automatic fixes were great. The only thing I see is the stacked license notes for both 2025 and 2024.

I think this is because of how the license insertion was set-up, where it would only recognize the exact current license header string. After looking into it, it looks like the hook can be configured to use fuzzy matching, which I've now set up (and fixed the existing duplicates)

[joserochh]

Thank you @AlexanderViand-Intel, I like this formatting better. And the automatic fixes were great. The only thing I see is the stacked license notes for both 2025 and 2024.

I think this is because of how the license insertion was set-up, where it would only recognize the exact current license header string. After looking into it, it looks like the hook can be configured to use fuzzy matching, which I've now set up (and fixed the existing duplicates)

There are still ~16 files with duplicated license. I know we should leave one note, but @kylanerace is trying to get clarification on the dates we need to have.

[kylanerace]

Thank you @AlexanderViand-Intel, I like this formatting better. And the automatic fixes were great. The only thing I see is the stacked license notes for both 2025 and 2024.

I think this is because of how the license insertion was set-up, where it would only recognize the exact current license header string. After looking into it, it looks like the hook can be configured to use fuzzy matching, which I've now set up (and fixed the existing duplicates)

There are still ~16 files with duplicated license. I know we should leave one note, but @kylanerace is trying to get clarification on the dates we need to have.

OK, the internal guidance is to do a range from the first license date of the file creation to now e.g. for a file licensed/created in 2024:

// Copyright (C) 2024 - 2025 Intel Corporation
// SPDX-License-Identifier: Apache-2.0

[AlexanderViand]

OK, the internal guidance is to do a range from the first license date of the file creation to now e.g. for a file licensed/created in 2024:

// Copyright (C) 2024 - 2025 Intel Corporation
// SPDX-License-Identifier: Apache-2.0

I don't think the pre-commit hook we use (or any, for that matter) can achieve that pattern, but what I was able to do just now is set the hook to allow prior years (this avoides the duplicates @joserochh noticed) and allows each file to have the date be its creation year. I think without writing a custom hook, this is probably as close as we can get :)

[joserochh]

LGTM

[kylanerace]

OK, the internal guidance is to do a range from the first license date of the file creation to now e.g. for a file licensed/created in 2024:
// Copyright (C) 2024 - 2025 Intel Corporation
// SPDX-License-Identifier: Apache-2.0

I don't think the pre-commit hook we use (or any, for that matter) can achieve that pattern, but what I was able to do just now is set the hook to allow prior years (this avoides the duplicates @joserochh noticed) and allows each file to have the date be its creation year. I think without writing a custom hook, this is probably as close as we can get :)

Yeah this sounds good. Otherwise It'll probably be non-tenable to maintain

[kylanerace]

LGTM, should be fine to merge pending #104 merging first, following @faberga's request

[AlexanderViand]

LGTM, should be fine to merge pending #104 merging first, following @faberga's request

With #104 now merged, I've rebased this PR onto main (there was a conflict before), should be good to go now.

[kylanerace]

LGTM, approved prior, now rebased. Should be good to go

[faberga]

@AlexanderViand-Intel, thanks for getting this PR in. Looking forward to PR #111.

[AlexanderViand-Intel]

@AlexanderViand-Intel, thanks for getting this PR in. Looking forward to PR #111.

#111 should be ready to review :)