Add Python imports sorter to CI and supply-chain review

[ajnelson-nist]

This PR adds and applies Python code-formatting to CI and adds a supply chain review step to keep the pinned formatter references "reasonably" up to date.

The extra logic in the check-supply-chain-pre-commit target will update the version-pin if an update is available, but will not raise a notice unless updating the tool version would induce a change in any of the Python files. (Changes in the Python files are checked with the pinned formatter version in CI.) These lessons were learned between case-utils PR 37 and CDO-Shapes-Example PR 1.

The new make target that creates a Python virtual environment, dedicated to the user's current repository clone, does this in order to avoid a Git logistical issue if make clean is run. (Described further in case-utils PR 37.)

Tools noted in the referenced PRs will be added in future PRs. isort is added as the first tool in order to avoid code conflicts with in-flight non-formatting revisions in other PRs.

Impact of merging this PR will be:

• Code formatting will follow a consistent style---currently scoped to imports-sorting---checked as part of CI.
• Contributors (who check CONTRIBUTE.md) should see instructions to run make, or otherwise install pre-commit in order to handle now-delegated code formatting decisions.
• Anyone who commits Python changes that would be stylistically altered by the auto-formatting will trigger a CI failure when the PR is filed. This is, in my opinion, an easy-enough fix for a project maintainer. Running make ; git commit --amend; git commit -m "Format" in the user's branch should provide a pushable patch atop the submission (noting the middle command fails, per pre-commit's execution style).

References

• Pre-Commit casework/CASE-Utilities-Python#37
• Relax pre-commit update enforcement Cyber-Domain-Ontology/CDO-Shapes-Example#1

Disclaimer

Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose.

[ajnelson-nist]

This PR is ready for review and merge.

[simsong]

Wow. A staggering number of changes. isort really has fun with this.
If you are going to do this, why not just go full blown autopep8 or black?

[ajnelson-nist]

Wow. A staggering number of changes. isort really has fun with this. If you are going to do this, why not just go full blown autopep8 or black?

I tried separating the changes into commits that were manual vs. commits that were automated effects. Sorry, I forgot to mention the right tab to look at first was the "Commits" tab, not the "Files changed" tab.

I put this PR in first because it's adding pre-commit and pre-commit maintenance logistics, and isort is the least-code-touching reviewer among the ones I was going to import from the CASE repositories' practices. I wanted this PR to check in on whether this pre-commit semi-automated maintenance practice is OK. I've found running pre-commit autoupdate nightly and keeping the pinned version up to date is a little too frequent for my maintenance preferences. Updating the pinned version whenever it changes code keeps pre-commit from mixing in unrelated effects to incoming contributions.

I will add Black in another PR after closing PR 45 tomorrow morning. I'm pretty sure Black would cause a few code conflicts with that PR while it's in-flight.

I hadn't heard of autopep8. The CASE repositories happen to use flake8. I'll try those as I add Black.

[simsong]

Flake8 is a linter, I think, and not a reformatted…

…

On Mon, Jun 24, 2024 at 12:13 PM Alex Nelson ***@***.***> wrote: Wow. A staggering number of changes. isort really has fun with this. If you are going to do this, why not just go full blown autopep8 <https://pypi.org/project/autopep8/> or black <https://github.com/psf/black>? I tried separating the changes into commits that were manual vs. commits that were automated effects. Sorry, I forgot to mention the right tab to look at first was the "Commits" tab, not the "Files changed" tab. I put this PR in first because it's adding pre-commit and pre-commit maintenance logistics, and isort is the least-code-touching reviewer among the ones I was going to import from the CASE repositories' practices. I wanted this PR to check in on whether this pre-commit semi-automated maintenance practice is OK. I've found running pre-commit autoupdate nightly and keeping the pinned version up to date is a little too frequent for my maintenance preferences. Updating the pinned version whenever it changes code keeps pre-commit from mixing in unrelated effects to incoming contributions. I will add Black in another PR after closing PR 45 <#45> tomorrow morning. I'm pretty sure Black would cause a few code conflicts with that PR while it's in-flight. I hadn't heard of autopep8. The CASE repositories happen to use flake8. I'll try those as I add Black. — Reply to this email directly, view it on GitHub <#48 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMFHLGIQ6UQN4E2HTIG3STZJBAT3AVCNFSM6AAAAABJWZBPH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBWHEZTINBVHA> . You are receiving this because your review was requested.Message ID: ***@***.***>